Repository navigation
perf(pr-pipeline): carry a deferred lane run's job read in the reconciler - #12752
Conversation
…iler A lost pr-verify or pr-review-main run that is re-runnable is never settled, so while all 3 re-run places are taken each pass read its attempt-1 jobs again. After the 2026-11-03 kill-switch window, 10-12 deferred pr-verify runs were re-read on every pass (05:02Z, 05:38Z) until each got a place. holdReason now reads a run still at attempt 1 from the settled-runs file's job carry while its listing shows the same head and updated_at, and carries a whole read whose every job's steps listed. A re-run changes the attempt and updated_at, so the carry drops; act still re-reads each run before it writes. Co-Authored-By: Claude Opus 5.5 <[email protected]> Claude-Session: https://claude.ai/code/session_01VcupomBPg7kuobwLoNpxEW
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
|
claude-review reviewed Code review: PR #12752 (incremental,
|
…carry The carry test freed every re-run place on its second pass, so it never reached the path that puts a carried read back for a run deferred again. Add a pass with the three re-runs still in flight: 201 and 202 stay deferred, are not read, keep their carried entries, and a third pass reads nothing. Removing the carry-back line now fails the test. Co-Authored-By: Claude Opus 5.5 <[email protected]>
|
claude-security-review reviewed Security review: PR #12752 (incremental since
|
Post-merge mutation testingKilled 5, survived 2, timeout 0, no coverage 0, invalid 0, not run 0.
Surviving mutants
The run's summary has the full report. |
No related issue: GITHUB_TOKEN trip 05:38Z attribution (reconcile-lost-runs catch-up)
Summary
GITHUB_TOKEN counter B tripped at 05:38Z on 2026-11-03. In that hour
maintenance-reconcile-lost-runsspent 356 calls over 4 runs. The lanes kill switch was on 04:34-04:55Z, so the 04:15Z and 04:38Z runs stopped with 1 call each: run 41579246488 logscheck-kill-switch: proceed=false reason=kill-switchandthe lanes kill switch stops this run; nothing read or re-run. They were not paced.rerun-failed-jobscalls for verdict runs (by design these take no place under the cap), 3 lane and review re-runs, and about 24 first reads of runs the switch had cancelled before they started, which it then settled. It also read 12 re-runnable pr-verify runs and deferred them withall 3 re-run places taken.workflow_dispatchby hand, so it did not go through pace.attempts/{n}/jobs=15, of which about 12 were pr-verify runs still waiting for a place (10 deferred, 2 re-run).The defect:
holdReasonreads a lane run's attempt-1 jobs before placement. Only a held run is settled, so a re-runnable run that is deferred is read again on every pass until it gets a place. The file's own rule says attempt-1 jobs of a completed run never change.Fix
holdReasonnow takes a lane run still at attempt 1 from the settled-runs file's existing job carry (jobs, keyedid:attempt) while the run listing shows the same head andupdated_at. It carries a whole read whose every job's steps listed, using the same checks as the PR-head job carry.updated_at, which drops the carry.SETTLED_VERSIONstays 3. The entries keep the existing shape, and a lane run's id never collides with a CI run's.Call delta:
attempts/1/jobsread per deferred run, plus annotation reads for any cut job.Verification
a lane run deferred for want of a place is not read again while it stays at attempt 1:attempts/1/jobsreads and re-runs the 2 deferred runs.updated_atreads the run again.[201, 202]and the test fails.node --testoverreconcile.test.mjs,infra-failure.test.mjsandcomponent-status.test.mjs: 177 pass, 0 fail.Related
gh-job-callsmonitor (local).workflows/{x}/runslistings (9 statuses x 2 lanes, plus intake, verdict and the carry lookup) and 22head_shalistings. That is the larger steady-state cost. The status split is deliberate (LANE_LIST_STATUSES).🤖 Generated with Claude Code
https://claude.ai/code/session_01VcupomBPg7kuobwLoNpxEW