Skip to content

test(bundle): serve a bodyless comment to approvalEvents through dist/index.js - #509

Open
hivecommons-hive[bot] wants to merge 1 commit into
mainfrom
quality/test-approve-bodyless-comment
Open

hivecommons-hive[bot] wants to merge 1 commit into
mainfrom
quality/test-approve-bodyless-comment

Conversation

@hivecommons-hive

Copy link
Copy Markdown
Contributor

Test Improvement

Files claimed: __tests__/bundle/approveBodylessComment.test.ts (new, test-only). Function: src/plugins/approve.ts approvalEvents (line 101, comment.body ?? ''). No src/, dist/ or workflow change.

GitHub's REST issue-comment schema types body as optional, but every bundle scenario that lists GET /issues/1/comments for the approve plugin serves a body on each comment. At main@1062ce7, npm run test:coverage:e2e reports the absent arm with zero hits (coverage-e2e/lcov.info: BRDA:101,4,1,0 under SF:src/plugins/approve.ts; the file at 96.62 % branches). The unit suite covers it (npx vitest run --coverage, same revision: 100 % lines / 98.87 % branches for the file).

Re-checked on #508's head (bodyless comments for comments.ts, requireMatchingLabel.ts, trigger.ts): still zero hits there, so this arm is disjoint from #508, and from #497 (effectiveKind / upsertNotifier, approve.ts 228/230/409/415), #498, #504 and #505.

Two pull_request_review cases, each listing a comment from an approver (bob) with no body, driving dist/index.js against the fake api:

  • bodyless comment alone: approve: #1 is not approved; nobody approves sdk/x.go, no label write, notifier suggests alice
  • bodyless comment followed by /approve from alice: the bodyless one is skipped, approved is added, notifier names alice only

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

  • npx eslint __tests__/bundle/approveBodylessComment.test.ts clean
  • npx vitest run __tests__/bundle/approveBodylessComment.test.ts: 2 passed
  • npm run test:coverage:e2e: 78 → 79 files, 487 → 489 tests; BRDA:101,4,1,0 → BRDA:101,4,1,2; src/plugins/approve.ts 96.62 → 97.19 % branches; suite 97.96 → 98.02 % branches (lines unchanged at 99.95 %)

Related Issue

Refs #499 — the hive folded this finding into #499 as a tracker; this PR lands only the approve.ts:101 e2e arm folded there. The threshold / docs/contributing.md deliverables that #499 was opened for ship in #500.


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

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

…/index.js

approvalEvents folds comment.body ?? '' (src/plugins/approve.ts:101) before
reading a command, but every bundle scenario served a body on each listed
comment, so the absent arm only ran in the unit suite. Two pull_request_review
cases now list a comment with no body: alone it is not an approval and an
approver is suggested; followed by /approve it is skipped and the approval
lands.

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 18, 2026 01:14
@hivecommons-hive hivecommons-hive Bot added the hold Indicates that a PR should not merge because someone has issued a /hold command. label Oct 18, 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