kevinveenbirkenbachandClaude Opus 5
04b79957a8
The hourly rerun bot looked only at the newest run's conclusion. When that run was cancelled while an older one was still pending, reviving it added a second waiter to the ref's global-ci concurrency group — and cancel-in-progress evicts only in_progress runs, so neither could start and every later dispatch queued behind them. Query the branch once with status included and leave it alone while anything on it is still active. The selection itself is unchanged; it now reads the same response instead of issuing a second one. Scope, measured rather than assumed: this does NOT explain today's deadlock. The blocking revival happened at 14:51 on an idle branch, which the guard permits, and the later revival at 15:51 never produced a second attempt (run 31405424413 is still attempt 1). The guard covers a narrower case than the incident that motivated it. scripts/github/rerun had no tests at all. The harness added here runs the script against a stubbed gh, following the pattern of tests/unit/scripts/tests/deploy/utils/test_rescue_index.py. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Run Reruns 🔁
Shell helpers that restart the unfinished parts of GitHub Actions workflow runs that were cancelled rather than completed.
Scope 📋
This directory contains helpers invoked from scheduled workflows. They call the GitHub Actions API to rerun the failed jobs of a cancelled run, never the run as a whole, so the work that already succeeded is kept. A run is a candidate only while it is recent and below its attempt ceiling; both bounds are passed in by the calling workflow, because a sweep without them would resurrect abandoned branches and retry a permanently cancelled run forever.
Helpers MUST NOT rerun a run whose conclusion is failure. A real defect has to be fixed, not retried, and the cancel helpers exist precisely so that a cancellation means "interrupted", not "broken".
For the workflow catalog that drives these calls see workflows.md.