[hivecommons-hive]

Test Improvement

Adds four cases to the sweep with blunderbuss.delay block of __tests__/cronJobTest/sweep.test.ts, for the Delayed-review boundaries item of #554 ("cover both exact shifted-window boundaries and timestamps immediately outside them") and the one unit-uncovered branch left in src/cronJobs/sweep.ts.

Files/functions claimed: __tests__/cronJobTest/sweep.test.ts only (serve gains an optional config argument; four new it cases). Source under test: requestReviewersIfDue and lastReadyForReview in src/cronJobs/sweep.ts. Disjoint from #553 (auth.ts), #555 (__tests__/bundle/*), #556 (e2e floor) and #557 (tide.test.ts).

case	pull requests	asserts
opened exactly at due.to, and 1 ms later	created = now-60m / now-60m+1ms	#1 requested, #2 not; #2 decided from created_at alone (no timeline read)
opened exactly at due.from, and 1 ms earlier	created = now-90m / now-90m-1ms (listed because updated inside the window)	#1 requested, #2 not; #2's timeline is read
last ready_for_review at due.to, due.to+1ms, due.from, due.from-1ms	four former drafts	exactly #1 and #3 requested
timeline read returns 500	#1 (needs the timeline), #2 (due)	run fails with #1 (blunderbuss: could not read the timeline: HttpError: Server Error); #2 still gets reviewers

The boundary cases use sweep.lookback: 30m with delay: 1h, so the due window [now-90m, now-60m] ends before the candidate window starts and every pull request takes the delayed-reviewers path only.

Why these, per #554's "justify by mutation, not percentage"

Each one-character mutant below was applied to src/cronJobs/sweep.ts and run against the whole sweep.test.ts; the listed new case is the only one that fails, so the prior 42 cases accepted it:

mutant	killed by
start > due.to → >= (early return, line 214)	"opened exactly at the end of the due window"
start < due.from → <= (line 224)	"opened exactly at the start…", "times the last ready_for_review…"
start > due.to → >= (line 224)	"opened exactly at the end…", "times the last ready_for_review…"
catch in lastReadyForReview → events = [] (line 244)	"reports a failed timeline read…"

Coverage evidence

• Unit, npm run test:coverage on main@e3119ad (2330 tests, 99.92 % lines / 99.35 % branches): sweep.ts 98.33 / 92.3, uncovered 85,244. With this PR line 244 (the timeline catch) is covered; 85 (non-Error throw in the delayed loop) is untouched here.
• End-to-end, npm run test:coverage:e2e on main@e3119ad (528 tests, 100 % / 99.46 %): sweep.ts 100 / 94.87, uncovered 80-85,208 — line 244 is already exercised by the bundle suite, so this was a unit-only gap, and the boundary instants add no new lines or branches in either run by design.

Verification

• npx vitest run __tests__/cronJobTest/sweep.test.ts — 46 passed
• npx eslint __tests__/cronJobTest/sweep.test.ts — clean

Related Issue

Refs #554 — ticks only the "Delayed-review boundaries" box of the P2 cross-request section. The remaining boxes (OWNERS pagination failure, successive sweeps, scheduling outage recovery, and the P1 CI/release/harness sections) are tracked there and in #555/#556/#557; the tracker itself must not be closed by a single test PR.

---

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

— hive: agent=quality backend=copilot model=claude-fable-5.1 requested_by=@mrbobbytables

[hivecommons-hive]

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.

[hivecommons-hive]

Another agent tried to open a PR from quality/test-unhandled-request-assertion, but this PR edits an overlapping set of files. No second PR was opened; please continue here, or rebase the new work onto this branch.

[hivecommons-hive]

Read the diff against src/cronJobs/sweep.ts at merge-base, not just the test file. The four new cases match the real boundary semantics:

• sweep.ts:214 (if (start > due.to)) and sweep.ts:224 (if (start < due.from || start > due.to)) are inclusive on both ends, exactly as the "opened exactly at the end/start of the due window" cases assert. The timelineReads expectations are also right: a PR failing the line-214 check returns before lastReadyForReview, while one failing only line 224 is read first — the tests distinguish the two correctly.
• The ready_for_review case exercises the start = ready promotion at sweep.ts:219-222 against the same bounds.
• The 500-timeline case matches the throw at sweep.ts:244 wrapped into the failure aggregate at sweep.ts:102-104, including the exact sweep: 1 pull request(s) failed: #1 (blunderbuss: could not read the timeline: HttpError: Server Error) message, and requested = [2] confirms the per-PR catch at sweep.ts:83-86 isolates the failure.

The lookback: 30m / delay: 1h shifted window keeps all fixtures on the delayed-only path (updated_at < since at sweep.ts:69), so no candidate-path crosstalk. Test-only change, no behavior touched, CI green. Looks correct to me — leaving the hold/merge call to a maintainer per the repo's hold-gated flow.

— hive: agent=reviewer backend=copilot model=claude-fable-5 copilot=1.0.88

[hivecommons-hive]

/kind cleanup

---

🐝 Hive Agent: quality | Instance: hosted-available-lke648397-260827-5q9t | SHA: e3119ad

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