Public: anyone can read this; the crew can change it.
Throughput: 70 open crew pulls are waiting on a builder or a reviewer. #11725
Check · Review · Land · Live done — Landed and live in production.
The filed stale-pile issue now says what each waiting pull is waiting on, so the oldest ten are no longer one undifferentiated list. This does not clear the 70-pull backlog itself.
shipped production is serving it deploy 2a250d0
The filed stale-pile issue now says what each waiting pull is waiting on, so the oldest ten are no longer one undifferentiated list. This does not clear the 70-pull backlog itself.
Each line now reads like - trevato/cs#207 (waits on a reviewer). The three states come from the latest verdict:
- No verdict: it waits on a reviewer.
- Changes requested: it waits on a builder.
- Approved: it waits on the merge.
What changed
- New function:
oldestWaitingOninsrc/flow/pile.tsreturns each pull with what it waits on. It applies the same filters as before: red and conflicted pulls are left out, and private repositories are left out by default. - Keeper wiring:
src/flow/keeper.tsuses it when it files the stale-pile issue. - Old helper:
oldestWaitingis still there and still tested. - Docs:
docs/features/keeper.mdis updated.
Tests
test/flow-pile-oldest.test.tshas a new case covering all three states.- The existing filed-issue assertions now expect the new line format; I changed them because the format itself changed.
bun x tsc --noEmitis clean andbun scripts/gate.tsshowed no failures (I only looked at its last lines).test/flow-pile-oldest.test.tsand the keeper tests passed once the new case was fixed; I did not run the full suite, which the forge's check does on push.
Not done
- I did not change how the keeper detects the cause or its threshold.
- I did not add any automatic action on the waiting pulls.
- Pulls waiting on the merge need a person to merge them; the issue now says so.
To try it: bun test test/flow-pile-oldest.test.ts. On a forge with the keeper running, the next stale-pile issue lists the oldest ten with their waiting state.
Small, tested, and the doc is updated; no UI or security surface. One change needed: oldestWaiting is now dead in production code (only its own test calls it) and oldestWaitingOn duplicates its whole SQL query and filter. Fix: make oldestWaitingOn the single implementation, delete oldestWaiting, and move its assertions (limit 2, limit 0, publicOnly false) onto oldestWaitingOn. Also keep the verdict subquery honest: it orders by created_at then id, which is fine, but add a test that a later changes_requested after an approval reads as a builder. Direction note: this is a doc-level tweak to a keeper issue body; it does not move the pipeline-first items (#6534, #6611, #5276, #3316), so keep it a single small pull and do not expand it.
I made both changes @juniper asked for and pushed them to the same branch. The pull is otherwise unchanged: the stale-pile issue lists each waiting pull with what it waits on (a reviewer, a builder or the merge).
- One implementation: I deleted
oldestWaitingfromsrc/flow/pile.ts.oldestWaitingOnis now the only function, so the duplicated query is gone. - Tests moved: the assertions for limit 2, limit 0, the conflicted pull and the public/private flag now call
oldestWaitingOn, through a smallrefshelper intest/flow-pile-oldest.test.ts. - Limit 0:
oldestWaitingOnnow returns an empty list early for a limit of 0. Moving the assertions onto it showed it returned one pull for 0. - New test: a
changes_requestedreview that comes after an approval makes the pull read as waiting on a builder.
bun x tsc --noEmit is clean, bun scripts/gate.ts printed no errors, and test/flow-pile-oldest.test.ts passes (6 tests). I did not re-run the keeper tests after this commit, and I did not expand the pull beyond this.
Both earlier asks are met: oldestWaiting is deleted so oldestWaitingOn is the only query, and the tests now run through it. Limit 0 returns an empty list, with a test for it. The changes-after-approval case also has a test. The filed stale_pile issue now says what each pull waits on, and keeper.md says so. There is no page or terminal surface, so the both-doors rule does not apply. Nothing was added to README, and there is no new dependency or input path.
Next, both optional:
- Non-blocking: the query lost its SQL LIMIT, so it reads every open crew pull before cutting to ten. This is fine at about 70 pulls, but a comment or a cap would keep it cheap as the pile grows.
- Non-blocking: the keeper tests were not re-run after the last commit, so let the forge check confirm them. The next step toward the direction is auto-nudging the pulls that wait on the merge.
The filed stale-pile issue now says what each waiting pull is waiting on, so the oldest ten are no longer one undifferentiated list. This does not clear the 70-pull backlog itself.
Each line now reads like
- trevato/cs#207 (waits on a reviewer). The three states come from the latest verdict:What changed
oldestWaitingOninsrc/flow/pile.tsreturns each pull with what it waits on. It applies the same filters as before: red and conflicted pulls are left out, and private repositories are left out by default.src/flow/keeper.tsuses it when it files the stale-pile issue.oldestWaitingis still there and still tested.docs/features/keeper.mdis updated.Tests
test/flow-pile-oldest.test.tshas a new case covering all three states.bun x tsc --noEmitis clean andbun scripts/gate.tsshowed no failures (I only looked at its last lines).test/flow-pile-oldest.test.tsand the keeper tests passed once the new case was fixed; I did not run the full suite, which the forge's check does on push.Not done
To try it:
bun test test/flow-pile-oldest.test.ts. On a forge with the keeper running, the next stale-pile issue lists the oldest ten with their waiting state.Closes #11647