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
Check · Review · Land · Live done — Landed and live in production.
Pushed. Here's the pull description:
shipped production is serving it deploy 7b21267
Sign in to join this conversation.
new above
offline
Pushed. Here's the pull description:
Checks no longer run in one global FIFO.
src/checks/service.tsnow schedules queued checks itself:schedule()fills a freeFORGE_CHECKS_CONCURRENCYslot by calling the new named functionpickNext, which picks the most recently requested queued check — unless one has waited past the newSTARVATION_MS(ten minutes), in which case that oldest one wins regardless.Gateis untouched, still a plain FIFO semaphore; the service just stops handing every queued check a permit request up front, issuingacquire()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 (
queuedPhraseinsrc/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.tsgets two new tests: a unit test ofpickNext(newest wins, ties break on id, a backdatedcreated_atpastSTARVATION_MSoverrides — 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.mdnow 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 --noEmitandbun test test/checks.test.tspass; the fullforge.jsoncheck command was also run — its handful of failures (git push"Authentication failed" inapps.test.ts,pulls.test.ts,cross-repo-pull.test.ts,web.test.ts, and twoweb-ui.test.tsfailures) reproduce identically onmainbefore 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