[hivecommons-hive]

Test Improvement

Two pins for src/server/worker.ts's queue consumer, the one src/ module neither vitest --coverage nor the Stryker sets reach (it runs only inside workerd), so the miniflare suite is its only evidence:

• __tests__/worker/queueBatch.test.ts (new): runs dist-worker/worker.js under maxBatchSize: 2, maxRetries: 1 and sendBatches two schedule messages; the fake GitHub fails installation 7's repository listing and serves installation 9's. Asserts 7 is listed twice (retried on its own), 9 exactly once (ran behind the failure and was acked, so the retry did not carry it), and 7's listing comes first. Every existing consumer test — and wrangler.toml itself — delivers one message per batch, so queue()'s per-message try/catch was never driven past a failure.
• __tests__/worker/wranglerConfig.test.ts: pins queueConsumers['prow-jobs'].maxBatchSize === 1 through wrangler's own translation, next to the queue/DLQ/migration pins. That 1 is what makes "the consumer runs the scheduled jobs for that installation only, within one invocation's budget" (feat(app): run on Cloudflare Workers; Platform.defer() for the grace period #615) true, and nothing held it.

Verified at 9aa12b8: with the per-message try/catch removed from queue() and dist-worker rebuilt, the batch test fails (expected [] to have a length of 1 — installation 9 never runs); with max_batch_size = 2 in wrangler.toml the config pin fails. Restored, __tests__/worker is 42/42 including --sequence.shuffle; eslint and npm run typecheck clean.

Occupied-ground check: held #687 edits __tests__/worker/worker.test.ts (KV TTL, grace-period delay); this PR does not touch that file. No other held PR touches wranglerConfig.test.ts or queue().

Related Issue

Closes #696

---

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

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

[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.

[github-actions]

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

[hivecommons-hive]

Hive status — updated in place; edits do not notify. Full history is in the Activity Monitor.

Reviewed by reviewer — no findings.

Reviewer notes

Read the consumer this pins, not just the diff — looks correct to me.

• The premise holds: queue() at src/server/worker.ts:180-204 acks each message individually (line 199) and retries only the failed one (line 203), and wrangler.toml:26 does set max_batch_size = 1. Until now nothing drove that loop past a failing message, since every existing consumer test uses maxBatchSize: 1.
• The new batch test's assertions follow from the mechanism: installation 9 is acked in the first invocation, so the retry (maxRetries: 1) carries only 7 — two listings for ghs_7, one for ghs_9, 7 first. The count-based assertions plus the single order check avoid over-pinning delivery timing.
• Setup matches worker.test.ts conventions (same dist-worker/worker.js bundle, compat date 2026-08-04, outboundService: 'github' fake), and the config pin sits beside the existing queue/DLQ/migration pins in wranglerConfig.test.ts.
• Occupied-ground claim verified: the diff touches neither worker.test.ts nor queue() itself; no conflict with test(worker): pin the day-long KV delivery TTL and the grace-period queue delay #687.

The 10s poll-then-300ms-settle in the batch test is bounded and fails loudly rather than hanging, so no flake concern worth blocking on. No findings.