Public: anyone can read this; the crew can change it.

A check starts on the newest push first, and a queued check says how long it has waited #39

Merged opened this

Check · Review · Land · Live done — Landed and live in production.

Merged

Pushed. Here's the pull description:

shipped production is serving it deploy 7b21267

opened this

Pushed. Here's the pull description:

Checks no longer run in one global FIFO. src/checks/service.ts now schedules queued checks itself: schedule() fills a free FORGE_CHECKS_CONCURRENCY slot by calling the new named function pickNext, which picks the most recently requested queued check — unless one has waited past the new STARVATION_MS (ten minutes), in which case that oldest one wins regardless. Gate is untouched, still a plain FIFO semaphore; the service just stops handing every queued check a permit request up front, issuing acquire() only for the check it has already chosen next. Superseding a queued check on a newer push to the same environment is unchanged.

A queued check on a pull now says how long it has waited: "Checks queued 12m" on the web (queuedPhrase in src/web/ui.ts), and the equivalent in the TUI's checks line (src/tui/screens/pull.ts), both without shifting the row's layout.

test/checks.test.ts gets two new tests: a unit test of pickNext (newest wins, ties break on id, a backdated created_at past STARVATION_MS overrides — no sleeping, time is set directly via SQL) and an integration test that holds the one concurrency slot, queues three checks on three environments oldest-first, and asserts they start newest-first once the slot frees. The existing supersede-while-queued test is untouched and still passes.

docs/APPS.md now states the queue's promise (newest first, ten-minute starvation bound, concurrency unchanged).

Left out: the merge-box's longer "Waiting on checks" prose doesn't repeat the wait duration (the checks line already does), to avoid growing that card.

Tried: bun x tsc --noEmit and bun test test/checks.test.ts pass; the full forge.json check command was also run — its handful of failures (git push "Authentication failed" in apps.test.ts, pulls.test.ts, cross-repo-pull.test.ts, web.test.ts, and two web-ui.test.ts failures) reproduce identically on main before this change, confirmed by stashing and re-running; they're a pre-existing sandbox git-auth issue, not caused by this pull.

🤖 Generated with Claude Code

Closes #33

Sign in to join this conversation.

↑↓ navigate ↵ open ⌘↵ its app esc close

Keyboard shortcuts

Docs