Repository navigation
pr-merge: re-judge a PR whose pr-merge/unarmed status outlived its cause #12862
Description
Problem
pr-merge stamps a failing pr-merge/unarmed status when it judges a PR and leaves it unarmed. Nothing re-judges that status once the cause clears, and the status itself makes the PR's merge state UNSTABLE.
During the 2026-11-03 review-token outage and the rate limits that followed, pr-merge stamped pr-merge/unarmed on lanes App PRs. One example is run 41621679690 on #12795 at 10:44Z. Their review lanes passed on re-run by about 15:00Z, but the status stayed red. Eleven green PRs (#12604 #12795 #12796 #12812 #12814 #12815 #12817 #12818 #12823 #12824 #12825) sat at 4 to 14 h, and #12604 reached 13.9 h. Every arm path that requires a CLEAN merge state refused them. The red check was the "unarmed" status itself.
They moved only because a local owner sweep was changed to accept UNSTABLE when ci-status, the only required check, is green. The merge lane itself still strands PRs the same way after the next outage.
Expected
When a PR's inputs change (a review lane completes, ci-status re-runs, or a hold label comes off), pr-merge re-judges the PR and either arms it or refreshes pr-merge/unarmed with the current reason. A stale pr-merge/unarmed should not outlive the condition that set it.
Done when
- A PR whose only blocker was a transient failure (outage, rate limit, kill switch) is re-judged by
pr-mergewithin one scheduled tick after the blocker clears, with no session involved. - A test covers it: a PR left unarmed on a failed review gets armed after the review re-run passes.
- The re-judge records the same telemetry as a first judgment, so stale-unarmed time can be measured.
Activity
github-actions commentedon Nov 3, 2026
The triage sweep dispatched intake triage for this issue (dispatch 1; 2 runs that reach intake, or 6 dispatches, hand it to a maintainer).
github-actions commentedon Nov 3, 2026
Proposed work class: work-class: scoped
Basis: automated intake triage; the lanes App applied this class.
Size: Small
Complexity: Low
Uncertainty: Known
Flags: none
Blocked by: none
Understood: a stale failing
pr-merge/unarmedstatus makes the PR UNSTABLE, and the merge-state gate then refuses it after the cause clears. The recorded decision picks the fix (treat UNSTABLE as ready only when that status is the sole failing non-required check), keeps the cron, and reuses LANE_SINCE.#12862 (comment)
That decision settles the open questions, so nothing further is asked.
Automated triage, applied by the lanes App.
melodic-automation-lanes commentedon Nov 3, 2026
Not admitted to the issue lane: no trusted-human acceptance criteria: a listed human must put the confirmed
- [ ]criteria in the body or post them as their own comment, or, on an issue a listed human filed, intake's newest refinement comment must hold them unedited. Admission takes the issue once each of those is met, when intake triages it again (.github/actions/resolve-config/admission-rules.json).15 remaining items
github-actions commentedon Nov 3, 2026
melodic-automation-lanes commentedon Nov 3, 2026
The work-resolve-issue run that
agent-readystarted waited in its slot past a change to its lane workflow files on main, so it stopped before any model turn. The run's report-outcome removed and addedagent-readyback to start a fresh run on main's workflow files. If this run ends the same way, it re-fires the issue again, waiting longer each time.github-actions commentedon Nov 3, 2026
melodic-automation-lanes commentedon Nov 3, 2026
The work-resolve-issue run that
agent-readystarted waited in its slot past a change to its lane workflow files on main, so it stopped before any model turn. The run's report-outcome removed and addedagent-readyback to start a fresh run on main's workflow files. If this run ends the same way, it re-fires the issue again, waiting longer each time.github-actions commentedon Nov 3, 2026
github-actions commentedon Nov 3, 2026