[kyle-sexton]

No related issue: follow-up to #8685; pr-verify exceeds 500 runs a day

Summary

The lost-run reconciler still fails: pr-verify has more than 500 runs
in the 24h window, so its paginated lane listing hits LANE_RUN_PAGES = 5 ("has more than 5 pages", [failing
run](https://github.com/melodic-software/claude-code-plugins/actions/run
s/39465225948)).

Fix

Stop listing the whole day. Read the lane's runs once per status in
LANE_LIST_STATUSES: the three LOST conclusions (cancelled,
timed_out, startup_failure) and the non-completed statuses
(in_progress, queued, waiting, requested, pending), each query
paginated with the same per-query cap, then dedupe by run id. The
in-flight count (non-completed, run_attempt > 1) is computed from the
merged set exactly as before, and a listing that exceeds the cap still
fails closed.

The status parameter of [list workflow runs for a
workflow](https://docs.github.com/en/rest/actions/workflow-runs#list-wor
kflow-runs-for-a-workflow) is documented as: "Returns workflow runs
with the check run status or conclusion that you specify." Its listed
values include cancelled, timed_out, in_progress, queued, waiting,
requested and pending. startup_failure is missing from that list, but
the live API accepts it (a repo-wide status=startup_failure query
returned a run whose conclusion is startup_failure), and combining
created= with status= returns matching runs.

Verification

• node --test in .github/scripts/maintenance-reconcile-lost-runs:
  34 pass, 0 fail.
• scripts/check-affected.sh --base origin/main --tests: 10 passed, 4
  skipped.
• The fake GitHub now honours status=. New tests: 700 succeeded plus
  2 cancelled runs plan the 2 lost runs without hitting the cap; queued
  and in-progress attempt-2 runs still take re-run places with 700
  succeeded runs listed; 150 lost runs span 2 pages.
• With reconcile.mjs from origin/main, the new tests fail (3 fail, 31
  pass) with "has more than 5 pages".

Related

Follow-up to #8685.

🤖 Generated with Claude Code

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-10-20T17:25:21.489076Z	cecb255	PR opened

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: cecb2555f3

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[github-actions]

claude-security-review reviewed 2658df4dad14174b6c8cd1dfc3a64a1a6d54c964: 0 finding(s), 0 as inline comments.

No security findings. The incremental change since cecb255 touches two files.

• reconcile.mjs reorders the LANE_LIST_STATUSES constant. It still queries the same set of statuses, only in a different order, so earlier-stage statuses are read first.
• reconcile.test.mjs adds one test that mocks a queued run moving to in-progress during the listing.

Neither change adds input handling, authorization logic, token or secret handling, injection surface, or any widening of workflow permissions. No instruction-surface deletions are involved, so the protected-class register lens does not apply. The change has no new security-relevant surface.

[github-actions]

claude-review reviewed 2658df4dad14174b6c8cd1dfc3a64a1a6d54c964: 0 finding(s), 0 as inline comments.

Incremental review of reconcile.mjs and reconcile.test.mjs since cecb255. I found no issues.

Change: LANE_LIST_STATUSES now reads the lost conclusions first, then requested, pending, waiting, queued, in_progress. A re-run moves forward through those statuses while the listing is read, so a later query still catches a run that left an earlier one. Previously in_progress was read before queued, so a run that moved from queued to in progress between the two queries was listed by neither. That undercounted the in-flight runs and let the reconciler start too many re-runs.

Checked by reading the code (reconcile.mjs:188-206):

• The merge by run id keeps the later snapshot, so the newer state wins when a run appears in two queries.
• The in-flight count (status !== "completed" && run_attempt > 1) is unchanged and still computed from the merged set.
• The new test mutates the fake runs from queued to in_progress when the status=queued query arrives. The in_progress query then lists them, so the expected reruns is []. With the old order the in_progress query would already have run, so those three runs would be missed and reruns would be [201]. I did not run the tests, so that is by reasoning only.
• One small remaining gap, which I'm not flagging: a run that is cancelled after the lost-conclusion queries but is still listed as in_progress is picked up on the next reconcile run.

Not verified: the PR's claim of 34 passing tests is the author's and unverified by me.