Skip to content

test(bundle): drive /close, /reopen and /approve on an issue whose user is null through dist/index.js - #505

Open
hivecommons-hive[bot] wants to merge 1 commit into
mainfrom
quality/test-null-issue-user
Open

hivecommons-hive[bot] wants to merge 1 commit into
mainfrom
quality/test-null-issue-user

Conversation

@hivecommons-hive

Copy link
Copy Markdown
Contributor

Test Improvement

Files claimed: __tests__/bundle/nullIssueUser.test.ts (new, test-only). Functions: src/issueComment/approve.ts approveByCoverage (line 94, issue?.user?.login ?? ''), src/issueComment/close.ts:33 and src/issueComment/reopen.ts:30 (the issue?.user?.login author shortcut). No src/, dist/ or workflow change.

GitHub's REST issue schema types user as nullable-simple-user (@octokit/openapi-types types.d.ts:16085): an issue whose author's account was deleted arrives with user: null. Every issue_comment bundle scenario builds its payload with comment() or prCommentEvent(), both of which assign issue.user.login, so the null arm never ran through dist/index.js. At main@1062ce7, npm run test:coverage:e2e reports src/issueComment/approve.ts at 96.15 % branches, line 94 uncovered — the file's last bundle-uncovered branch (unit: 100 / 100 / 100 / 100).

Four cases, each sending payload.issue.user = null:

  • /close by a collaborator: not the author, so the collaborator read decides; PATCH { state: 'closed' }; request sequence asserted.
  • /close by a non-collaborator: falls to authorization.close (the configuration reads), nothing written.
  • /reopen by a collaborator: collaborator read, then PATCH { state: 'open' }.
  • issue_comment /approve with require_self_approval: true by an OWNERS approver (alice): not refused as a self-approval, approved is added and the notifier names her.

Verification (local, this branch, main@1062ce7 + this commit)

  • npx vitest run __tests__/bundle/nullIssueUser.test.ts: 4 passed.
  • npm run test:coverage:e2e: 491 → 495 tests; src/issueComment/approve.ts 96.15 → 100 % branches, close.ts / reopen.ts 100 %; suite branches 97.96 → 98.02 % (lines/functions/statements unchanged at 99.95 / 100 / 99.96).
  • npm run test:coverage: 2124 passed, unchanged (unit does not run __tests__/bundle coverage).
  • npx eslint on the new file: clean.

Related Issue

None: the hive's issue relay consolidated the finding into #499 twice (a false match on shared file names — #499 is the unit threshold floor, carried by #500), so this PR carries the finding itself. Disjoint from held PRs #497 (src/plugins/approve.ts, meow.ts), #498 (tideOptionalFields.test.ts), #500/#502 (thresholds), #501 (docsYamlExamples.test.ts), #504 (githubApiUrlDefault.test.ts).


Filed by quality agent (hold-gated mode). Human review required.

— hive: agent=quality backend=copilot model=claude-fable-5.1 copilot=1.0.88

…er is null through dist/index.js

GitHub's issue schema types user as nullable-simple-user (a deleted
account), so the ?.user?.login author shortcut in close.ts and reopen.ts
and the ?? '' in approve.ts' require_self_approval check each carry a
null arm. No bundle scenario sent an authorless issue, so approve.ts:94
was the last branch of src/issueComment/approve.ts that npm run
test:coverage:e2e did not reach.

The new file sends payload.issue.user = null through dist/index.js:
/close and /reopen by a collaborator are decided by the collaborator
read (and /close by a non-collaborator falls to authorization.close),
and an issue_comment /approve with require_self_approval on is not
refused as a self-approval and approves.

Signed-off-by: quality <280983584+hivecommons-hive[bot]@users.noreply.github.com>
@hivecommons-hive
hivecommons-hive Bot requested a review from jpmcb as a code owner October 17, 2026 19:03
@hivecommons-hive hivecommons-hive Bot added the hold Indicates that a PR should not merge because someone has issued a /hold command. label Oct 17, 2026
@hivecommons-hive

Copy link
Copy Markdown
Contributor Author

Important

Held for human review by the hive's ACMM level gate.

This PR was opened by the "quality" agent while Hive policy required a human checkpoint for that agent. Agent PRs are held at ACMM L3–L5; an outreach PR that targets a repository this hive does not manage is held at every level because it publishes project-facing communication into someone else's project.

Hive will keep the hold label until a human removes it. Operators can make a deliberate one-off release during an ACMM level change with release_level_holds=true, but level changes never release this hold automatically.

@github-actions

Copy link
Copy Markdown
Contributor

Please add a kind label with /kind feature, /kind failing-test or /kind cleanup.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

hold Indicates that a PR should not merge because someone has issued a /hold command. needs-kind

Projects

None yet

Development

Successfully merging this pull request may close these issues.

0 participants