Repository navigation
pr-pipeline: clear a feedback-not-landed escalation once the head moves and no lane thread is open #10074
Description
Problem
clear-escalations.mjs clears a pr-unblock escalation once its reason no longer holds, but its CHECKS table (.github/scripts/pr-merge/clear-escalations.mjs:120-132) covers only workflow-staged, unresolved-conflict, protected-path-conflict and feedback-protected-path. A feedback-not-landed escalation stays labeled after the cause is gone.
Example: #9965 escalated feedback-not-landed at resume key e5183af3; the head moved to 898665b3 with no unresolved review thread left, and ci-status stayed red only on the needs-human label until a person removed it.
Owner decision (2026-10-25)
A stop is worth a person only for security, intent, or a real charge. feedback-not-landed is none of those once the head has moved.
Fix
Add a feedback-not-landed entry to CHECKS in clear-escalations.mjs: the reason no longer holds when the head differs from the escalation's resume key and no review thread the lane replied to is left unresolved. Reuse the existing clearing path; add no second mechanism.
Done when
clear-escalations.test.mjscovers: head moved and no open lane thread clears; head unchanged keeps; an open lane thread keeps.
Activity
github-actions commentedon Oct 25, 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
#10074 (comment)
This decision settles the open questions: the resume key is passed into the check, lane threads are found by paging reviewThreads, and the rule that a person who spoke keeps the label stays. Nothing is left to ask. The work is a bounded change to the clear-escalations script plus its tests.
Automated triage, applied by the lanes App.
melodic-automation-lanes commentedon Oct 25, 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).melodic-automation-lanes commentedon Oct 25, 2026
The latest triage verdict holds nothing: the issue is at
status: ready.melodic-automation-lanes commentedon Oct 25, 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: Add a feedback-not-landed entry to CHECKS in clear-escalations.mjs that clears when the PR head differs from the escalation's resume key and no review thread the lane replied to is unresolved, with three tests.
Related work
Open questions
RECOMMENDED: Yes: parse the key from line 2 of each feedback-not-landed escalation with RESUME_KEY and pass it in; keep the label if any such key equals the current head. Basis: .github/scripts/pr-merge/clear-escalations.mjs:253 and .github/scripts/pr-unblock/gate-source.mjs:21,85
RECOMMENDED: Page reviewThreads over GraphQL and treat a thread as a lane thread when any comment is authored by the lanes bot login (pass bot into CHECKS); any unresolved one, or a truncated listing, keeps the label. Basis: .github/scripts/pr-unblock/address-feedback.mjs:596-616
RECOMMENDED: No: keep the existing person-spoke rule, so the new check only runs after it passes. Basis: .github/scripts/pr-merge/clear-escalations.mjs:24-27,226-229
Sources read
Automated refinement by the lanes App. Answer with a comment whose first line is
**Decision recorded.**.kyle-sexton commentedon Oct 26, 2026
Decision recorded. The owner answered in the Refinement session (2026-10-25), deciding the open items below on the facts:
Question asked: Accept the three implementation answers below for the
feedback-not-landedclear check?The body's owner decision (2026-10-25) settles the intent:
Open items come from intake's refinement: #10074 (comment)
github,repo,pullandmainSha, not the escalation's resume key. Mayverdict()pass the resume key in?Decided: Yes. Parse the key from each
feedback-not-landedescalation's resume-key line and pass it in; keep the label if any key equals the current head. Basis: origin/main.github/scripts/pr-merge/clear-escalations.mjs:253(the CHECKS call) and.github/scripts/pr-unblock/gate-source.mjs:21,82-86(RESUME_KEY on line 2 of each escalation). Intake's answer kept.Decided: Page
reviewThreadsover GraphQL as address-feedback does, and count a thread as the lane's when any comment is by the lanes bot login. Any unresolved one, or a listing that may be cut short, keeps the label. Basis:.github/scripts/pr-unblock/address-feedback.mjs:614-622,737-742;clear-escalations.mjs:35-36(a cut-short listing counts as the reason holding). Intake's answer kept.Decided: No. Keep the person-spoke rule; the new check runs only after it passes. A person speaking is an intent signal, which the owner decision still counts. Basis:
clear-escalations.mjs:24-27,224-229. Intake's answer kept.Acceptance criteria:
clear-escalations.test.mjscovers: head moved and no open lane thread clears; head unchanged keeps; an open lane thread keeps. (Converted from the body's Done when, wording unchanged.)clear-escalations.mjshas afeedback-not-landedentry inCHECKSand adds no second clearing mechanism.feedback-not-landed, with a test case.