Repository navigation
fix(pr-pipeline): lift a stale needs-session label once its lane cause is gone #11200
Description
Problem
The needs-session label routes a lane stop to a session (#11175 for ci-fix-escalated, and #10954 for the other reroutes). No lane removes a stale needs-session label once a same-head retry or a new head clears the stop. The pr-pipeline README now tells the session that finds the head green to remove it, which is a manual step. Both the builder's security reviewer and claude-review flagged the gap on #11175.
Proposed fix
Extend .github/scripts/pr-merge/clear-escalations.mjs so it lifts needs-session when the lane cause behind it is gone. This is merge-gate code that already holds the permission it needs, so no new permission is required.
Rejected alternative: grant issues: write to the report-stop-status job in pr-unblock.yml. That widens a permission, which is the owner's decision.
Done when
- A PR carrying
needs-sessionwhose stop is mended on the same head or a new head loses the label on the next clear-escalations pass, with no person or session acting. - A test covers both the same-head and the new-head case, and fails before the change.
Activity
github-actions commentedon Oct 30, 2026
Proposed work class: work-class: scoped
Basis: automated intake triage; the lanes App applied this class.
Size: Small
Complexity: Medium
Uncertainty: Known
Flags: none
Blocked by: none
You want clear-escalations to lift a stale
needs-sessionlabel once the stop behind it is mended, on the same head or on a new head. The same-head half is already on main. The new-head half is the work left.#11200 (comment)
That decision settles every open question. It narrows the new-head lift so that
dependency-workflow-unpinnedkeeps the label. It also adds the done-when items, including a new-head-still-failing test case. No further questions. No duplicate found among open issues.Automated triage, applied by the lanes App.
melodic-automation-lanes commentedon Oct 30, 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; it carries duplicate. Admission takes the issue once each of those is met, when intake triages it again (.github/actions/resolve-config/admission-rules.json).melodic-automation-lanes commentedon Oct 30, 2026
The latest triage verdict holds nothing: the issue is at
status: ready.melodic-automation-lanes commentedon Oct 30, 2026
Refinement. A read-only run explored this repository, searched its issues and pull requests, and read the allowed docs to draft what follows. On an issue a listed human filed, it counts as the issue's spec once posted, while unedited; it is still model text, so check it.
Intended outcome: clear-escalations.mjs lifts a stale needs-session label once the stop is mended on the same head or a new head, with a test for both cases; this likely continues in #11114 and #11087.
Related work
Open questions
RECOMMENDED: Yes. Close it as a duplicate and add the new-head case and the rejected alternative to #11114. Basis: Intake triage comment names #11114 and #11087 as overlapping, and the issue carries the duplicate label.
RECOMMENDED: Assume neither does until an owner confirms, and add it to #11114's done-when. Basis: judgment
RECOMMENDED: Confirm the base branch includes the #11175 and #10954 changes before work starts. Basis: judgment
Sources read
To answer, post a comment that starts with this line:
Automated refinement by the lanes App. Answer with a comment whose first line is
**Decision recorded.**.kyle-sexton commentedon Oct 31, 2026
Decision recorded.
This answers the three open questions in the 2026-10-30 refinement. Code read at origin/main
fc1a7072d0. Agents decided this on evidence under standing direction §1.Q1. Not a duplicate any more. #11114 closed as not planned on 2026-10-31, a duplicate of #11087. #11087 closed as completed through #11476 (
705b9f73f7), which covers the same-head half only: theclear-escalationssweep liftsneeds-sessionwhen the stop's failing status is cleared on the stop's own head (.github/scripts/pr-merge/clear-escalations.mjs:138-144,sessionVerdictat:1483-1543). The new-head half is still open, and the code says so: "A later head carries no status, so a stop on an older head keeps it for a session" (:1492-1494). This issue carries that half. Theduplicatelabel comes off.Q2. Neither covers the new head. #11087's criteria name a same-head retry and a cause still present (its record), and the code above confirms it.
Q3. Yes. The label, its routes and the sweep are on main. Twelve routes set
needs-session(.github/scripts/pr-unblock/escalation-routes.json):protected-path-conflict,conflict-patch-protected-path,feedback-protected-path;dependency-round-cap,dependency-fix-not-landed,dependency-config-unreadable,dependency-files-truncated,dependency-control-uncited,dependency-workflow-unpinned;ci-fix-protected-path,ci-fix-weaken-required,ci-fix-escalated.What proves a stop mended on a new head. A stop's status sits on the stop's head, and
report-escalation.sh clearposts success only over a failure on that same head (.github/scripts/pr-unblock/report-escalation.sh:66-87). So nothing marks a new head as mended. The sweep reads the current head instead. The label comes off when all three hold:pr-unblock/*status for that stop's activity;ciPasses,:448; passing conclusions at:237).ciPassesleaves outci-statusitself (:468), so aci-statusthe label keeps red does not block the lift.If the cause holds, the lane stops again on the new head and its stop puts the label back, the same way pr-merge's head-moved path works (
clear-escalations.mjs:89-100). The reads use the statuses and checks the sweep's job token already holds since #11476, so no permission changes.One route is left out of the new-head lift:
dependency-workflow-unpinnedmarks a workflow or action change beyond a full-SHA pin swap, which green checks do not judge, so on a new head it keeps the label until its own lane clears it on that head.needs-sessionwhose stop is mended on the same head or a new head loses the label on the nextclear-escalationspass, with no person or session acting, except adependency-workflow-unpinnedstop on a new head, below. (body, narrowed for that one route)pr-unblock/*status for those stops' activities fails at the current head, and the current head's checks pass byciPasses.pr-unblock/*status for a stop's activity fails at that head or its checks do not pass byciPasses.dependency-workflow-unpinnedkeeps the label; only its same-head clear removes it.clear-escalations.test.mjscovers the same-head case, the new-head case and the new-head-still-failing case. (body: a test covers both cases)sessionVerdictcomment no longer says a stop on an older head keeps the label for a session.Route: issue lane. The change is in
clear-escalations.mjsand its tests, with no workflow edit. The body also asks that the test fail before the change. The lane cannot run node, so CI runs the suite, and the PR shows the new cases failing against main's module. Labels: it already carriesstatus: confirmed; removestatus: needs-decisionandduplicate.github-actions commentedon Oct 31, 2026
github-actions commentedon Oct 31, 2026