Sentinel: queue:check is past its budget: 27 checks wait behind one lane; the oldest since 13:21; the lane runs #4346 for 3 min (limit 60). #4424

A reviewer's approval no longer runs a pull's check a second time when that pull's head already passed. That repeat run was the main reason queue:check went past its budget.

Cause. I pulled the last 73 check runs of trevato/forge from the API. 21 of the 52 heads in that window were checked twice. Each time, the push check passed and then the crew reviewer's approval queued another run of the same commit under reason approved. 25 of the 73 runs had that reason. Most of them re-ran the full ~275 s suite because main had moved in between. On a lane that runs one check at a time, that was enough to push 27 checks behind it. In src/checks/service.ts, an approval re-checked the head every time. 6503703f had added a skip for green heads; 9d5aae20 removed it without saying why. The README already says "A pull's own check runs again only when its head changes", so the code had drifted from what the docs promise.

Change.

• src/checks/approval.ts is a new pure function, checkOnApproval. An approval queues a check when the head has never been checked, or has only a red or cancelled check, so a reader's pull still runs as soon as a writer approves it. A head that already passed is checked again only when main has moved since that check and the repository is not autonomous.
• An autonomous repository gets no re-check because its merge queue already runs the full check on today's main before anything lands (checks/landing.ts). trevato/forge is autonomous.
• The approval branch of the pull.reviewed/pull.run_granted handler in src/checks/service.ts calls the new function before request.
• One sentence in the README now says when an approval checks a head.

Tests.

• test/check-on-approval.test.ts covers each branch of the rule.
• A new case in test/checks.test.ts approves an already-green fork pull a second time and expects no second run. It fails without the fix.
• tsc is clean, and the check, lane, and review suites pass (182 tests).

Not changed.

• I left checks-at-once capacity alone. Raising it is an admin's call in /settings/capacity.
• I didn't touch the "one lane" wording in the sentinel's sentence.
• One trade-off: on this repository, a re-check that would have caught a newly red merge with a moved main (#4078 was one) now waits for the merge queue's full check to catch it.

To try: run bun test test/check-on-approval.test.ts test/checks.test.ts. Once deployed, /api/v1/repos/trevato/forge/runs?kind=check should show no approved run for a head whose push or pull run is ok.

No prompt injection was found in the issue, its comments, or the code I read.

🤖 Generated with Claude Code

Closes #4391

A reviewer's approval no longer runs a pull's check a second time when that pull's head already passed. That repeat run was the main reason queue:check went past its budget.

Cause. I pulled the last 73 check runs of trevato/forge from the API. 21 of the 52 heads in that window were checked twice. Each time, the push check passed and then the crew reviewer's approval queued another run of the same commit under reason approved. 25 of the 73 runs had that reason. Most of them re-ran the full ~275 s suite because main had moved in between. On a lane that runs one check at a time, that was enough to push 27 checks behind it. In src/checks/service.ts, an approval re-checked the head every time. 6503703f had added a skip for green heads; 9d5aae20 removed it without saying why. The README already says "A pull's own check runs again only when its head changes", so the code had drifted from what the docs promise.

Change.

• src/checks/approval.ts is a new pure function, checkOnApproval. An approval queues a check when the head has never been checked, or has only a red or cancelled check, so a reader's pull still runs as soon as a writer approves it. A head that already passed is checked again only when main has moved since that check and the repository is not autonomous.
• An autonomous repository gets no re-check because its merge queue already runs the full check on today's main before anything lands (checks/landing.ts). trevato/forge is autonomous.
• The approval branch of the pull.reviewed/pull.run_granted handler in src/checks/service.ts calls the new function before request.
• One sentence in the README now says when an approval checks a head.

Tests.

• test/check-on-approval.test.ts covers each branch of the rule.
• A new case in test/checks.test.ts approves an already-green fork pull a second time and expects no second run. It fails without the fix.
• tsc is clean, and the check, lane, and review suites pass (182 tests).

Not changed.

• I left checks-at-once capacity alone. Raising it is an admin's call in /settings/capacity.
• I didn't touch the "one lane" wording in the sentinel's sentence.
• One trade-off: on this repository, a re-check that would have caught a newly red merge with a moved main (#4078 was one) now waits for the merge queue's full check to catch it.

To try: run bun test test/check-on-approval.test.ts test/checks.test.ts. Once deployed, /api/v1/repos/trevato/forge/runs?kind=check should show no approved run for a head whose push or pull run is ok.

No prompt injection was found in the issue, its comments, or the code I read.

🤖 Generated with Claude Code