[debuggingfuture]

What

Durable verdict delivery from ADR-0009: a computed verdict reaches the pull request even when the installation's GitHub quota runs short.

• Bucketed queue positions. A waiter writes its queue position only when it crosses a bucket boundary (1, 2-5, 6-20, over 20) and at most once a minute (admission-summary.ts, admission loop in workflow.ts). The check-run shows the bucket, not the exact count.
• Retry-After and reset honoured. Each retry in the checks client (packages/runtime-cf/src/checks-github.ts) waits at least as long as GitHub asked. A wait longer than 30 s degrades the call and marks the installation exhausted until the wait lapses, so later calls do not spend requests on a wait GitHub already named.
• Verdict reserve. Every check-run response's x-ratelimit-remaining / -limit / -reset feeds a per-installation quota cache (github-quota.ts). At or under 10% of the window, progress stops; create, update and conclude proceed. The cache holds GitHub's last answer per isolate. The quota itself lives on GitHub and each response refreshes it, so the worst case is one extra call per isolate past the reserve.
• Create at conclusion. ChecksService.conclude completes the check-run, or creates it already completed when the opener degraded to the noop sentinel id. It is total and returns delivered (with the check-run id), undelivered (worth sending again: rate limit, outage, missing credentials) or refused (404 or 422: GitHub rejects that write for good). The workflow runs it in a durable deliver-verdict step, so a replay never creates a second check-run.
• executions.delivered_at. Migration 0012 adds delivered_at, delivery_refused_at and installation_id. The workflow stores the installation with the check-run id and stamps delivered_at when the conclusion lands.
• Reconcile sweep. */10 * * * * (armed in wrangler.jsonc, routed by routes/scheduled.ts) re-sends the conclusion of every finished execution (success / failure / skipped) that has an installation and neither delivered_at nor delivery_refused_at. It works oldest first, skips rows finished less than 10 minutes ago and rows older than 7 days, and handles at most 50 rows a tick. The first undelivered row of an installation stops the sweep for that installation until the next tick. A refused row stamps delivery_refused_at and leaves the queue, so it never holds up the newer rows of its installation. Cron parity exempts the sweep cron and asserts it is armed.

Why

Without a write budget, a burst of queued runs spent an installation's hourly quota on position updates. Check-runs then failed to open or never concluded, and verdicts computed in D1 never reached GitHub, which looks the same as a hang.

Notes

• Merge order: 0012 follows 0011_spend_guard.sql from feat(spend): spend guard and admission classes — budget, burn ceiling, scaled polls, interactive class #236. Merge feat(spend): spend guard and admission classes — budget, burn ceiling, scaled polls, interactive class #236 first, or renumber if it lands later.
• installation_id is a column beyond the ADR's delivered_at. It marks a row as owing a verdict on GitHub: rows from a deploy or dispatch with no live Checks Layer, and every row written before this migration, carry none, so the sweep leaves them alone.
• A conclusion GitHub refuses with a client error comes back as data instead of a defect: 401 as undelivered (an App-wide credential fault the sweep keeps retrying), 404 and 422 as refused. The workflow logs either; the sweep sends its own short summary once more and stamps delivery_refused_at if GitHub refuses that too.

Spec: specs/adr/0009-fast-trustworthy-verdicts.md § Durable verdict delivery (proposed in #232)

Testing: pnpm lint, pnpm typecheck and pnpm test (207 files, 2854 passed) are green. New tests cover the bucket boundaries and the once-a-minute bound (admission-summary.test.ts); quota headers and the observe hook (http.test.ts, check-runs.test.ts); reserve, exhaustion and Retry-After waits (github-quota.test.ts, checks-github.test.ts); create-at-conclusion, undelivered and refused outcomes (checks-github.test.ts); sweep order, bounds, per-installation stop, refused rows leaving the queue and noop-id recording (delivery-sweep.test.ts); and sweep cron routing (scheduled.test.ts, cron-parity.test.ts).

[flaredispatch-fractalboxdev]

AI code review — 💬 Comment

Risk tier: full · 0 critical · 2 warnings · 1 suggestions

Reviewers: security 0 · performance 1 · code-quality 0 · documentation 2 · release-management 0 · compliance 0 · agents-md 0

1. ⚠️ Warning — Sweep processes all 50 deliveries serially

📍 apps/dispatcher/src/delivery-sweep.ts:121-131

Each row waits for 'conclude' and then 'markDelivered' before the next row starts. With 50 rows, GitHub latency and retry/backoff delays can make one tick run for many minutes or overlap the next 10-minute cron tick, causing duplicate reconciliation work and poor throughput. Use bounded concurrency (ideally grouped/limited per installation) or otherwise enforce a sweep deadline and resume pagination on the next tick.

2. 💡 Suggestion — Migration comment points to the wrong source path

📍 infra/migrations/0012_verdict_delivery.sql:16-17

The comment references 'apps/dispatcher/delivery-sweep.ts', but the implementation is under 'apps/dispatcher/src/delivery-sweep.ts'. Update the path so operators can locate the sweep directly.

3. ⚠️ Warning — Sweep comment incorrectly says no verdict is owed without credentials

📍 apps/dispatcher/src/routes/scheduled.ts:159-160

A deployment without App credentials can still contain executions with an installation_id and a missing delivered_at from an earlier deployment. The sweep is skipped because delivery cannot currently be attempted, not because no verdict is owed. Reword this comment to avoid implying those rows are not owed delivery.

📋 View full logs & reviewed diff ↗