fix(ci): recover a cancelled run that is the newest for a static head

[BunsDev]

Follow-up to #4505, which I merged earlier today. It got the approval gate
right and one adjacent case wrong.

The gap

#4505 classified cancelled as coverage:

A cancelled run is normally superseded by a newer push that has its own
run, and recovering it would fight that.

True in the common case. False when the cancelled run is the newest for a
head that has not moved — nothing is coming to replace it, the required context
reports cancelled rather than success forever, and the PR is wedged with no
path to green. Which is exactly the state ci-recovery exists to clear.

Observed live

PR #4514, head 02f74118ff: exactly one CI run, cancelled, head static.

$ pnpm ci:recovery
CI recovery: 5 open PRs scanned; 0 eligible.

Blocked, with no local remedy — gh run rerun needs admin rights, and recovery
declined because it believed the head was covered. Its owner eventually had to
push a bump.

The fix

Judge the latest run, not "every run is cancelled". GitHub's rollup shows
the most recent check-run per name, so an older success underneath a newer
cancellation does not unblock the PR and must not suppress recovery either.

cancelled moves out of isCoverage entirely. That predicate cannot see a
run's position among its siblings, and position is the whole question; it now
documents that rather than pretending to answer it.

Existing exclusions unchanged:

• a failure is still coverage — it reported a verdict;
• a startup_failure is still left to a human, since re-dispatching a
  workflow that cannot start would loop.

Tests

cancelled drops out of the still-coverage list, and two new cases pin both
directions:

• cancelled-and-newest → recovers, reason cancelled_latest_run;
• cancelled-underneath-a-newer-run → left alone.

22 pass, plus the workflow contract test and 1611 files wired.

Also verified against live GitHub: the scan now correctly returns 0 eligible,
because #4514's owner pushed a new head whose run is in progress. The unit tests
are what pin the wedge itself.

Closes cave-geaji.

[Copilot]

Pull request overview

This PR updates the CI recovery script to treat a cancelled workflow run as recoverable when it is the latest run for an unchanged PR head, addressing a wedge where the required status can remain cancelled indefinitely with no newer run coming to replace it.

Changes:

• Move cancelled handling out of the generic “coverage” predicate and into decideRecovery where run ordering (latest vs older) is available.
• Add recovery logic for latest.conclusion === "cancelled" with a new reason cancelled_latest_run.
• Extend unit tests to cover both “cancelled newest → recover” and “cancelled older under a newer run → do not recover”.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
scripts/ci-recovery.mjs	Adds explicit handling for a cancelled latest run and updates coverage documentation/logic boundaries.
scripts/ci-recovery.test.mjs	Updates coverage expectations and adds test cases pinning the cancelled-latest vs cancelled-superseded behaviors.

Suppressed comments (1)

scripts/ci-recovery.mjs:195

• isCoverage still treats conclusion: "cancelled" as coverage (run.conclusion !== APPROVAL_GATED). That contradicts the updated docstring (“cancelled is judged by POSITION … so it deliberately does not try to answer that”) and can suppress recovery in mixed cases (e.g., an approval-gated newest run plus an older cancelled run would hit runs.some(isCoverage) and return ci_present). Treat cancelled as non-coverage here so only the latest-position check in decideRecovery controls it.

function isCoverage(run) {
  if (run.status === "in_progress") return true;
  if (run.status !== "completed") return false;
  return run.conclusion !== APPROVAL_GATED;
}

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.