Repository navigation
fix(pr-pipeline): retry a failed intake hand-off in the demotion alert instead of labeling needs-human #13022
Description
Refs: #11022
Problem
When the post-merge demotion alert cannot hand a fix or quarantine issue to intake triage, it labels that issue needs-human:
.github/workflows/post-merge-demotion-alert.yml:526-528: a quarantine issue not sent to intake triage getsneeds-human..github/workflows/post-merge-demotion-alert.yml:1184-1191: an undelivered fix issue getsneeds-human, and the record gets the comment built at:1261("Fix work not handed to intake on this run, labeled needs-human for a person").
#12279 added this under #11022. A failed hand-off to intake is none of the owner's three stop reasons: an intent or vision change, a finding that changes the primary design, or a real HIGH/CRITICAL security or billing risk. So routing it to a person is a workflow defect, not a designed stop. Nothing retries the hand-off afterwards, so the issue waits on the owner for something a later run could do itself.
Current exposure: none of the 3 open needs-human issues (#12108, #12043, #9905) came from this path, so there is nothing to clean up today.
Done when
- On a failed hand-off, the alert does not add
needs-human. It records the failure visibly instead, with a designed-stop label or a reason-marked status that names the undelivered issue, and the next run retries the hand-off. needs-humanstays only where the issue body itself names one of the owner's stop reasons. The canary and revert records at:1094-1096and:1148-1154are reviewed against that rule.- A test shows that a failed hand-off adds no
needs-humanand that the next run retries it.
Notes
- Owner lane: poteto (post-merge area).
post-merge-demotion-alert.ymlis a workflow file, so the change is pushed from a host session. - Found by the R17 replacement of docs(loop-lane): route the five guardrail escalation classes to lanes and name the intake injection hold #12968 (docs(loop-lane): route the five guardrail escalation classes to lanes and name the intake injection hold #13021), whose README update now describes this behavior as it is, without calling it a kept control.
Metadata
Metadata
Assignees
Labels
Type
Fields
Work status
confirmed
Activity
github-actions commentedon Nov 4, 2026
Proposed work class: work-class: scoped
Basis: automated intake triage; the lanes App applied this class.
Size: Medium
Complexity: Medium
Uncertainty: Known
Flags: none
Blocked by: none
Understood: when the post-merge demotion alert can't hand a fix or quarantine issue to intake triage, it labels the issue
needs-human. You want it to record the failure visibly without that label and retry the hand-off on the next run. You also want the canary and revert records reviewed against the owner-stop rule, and a test covering both behaviors.The done-when items are specific, so I'm asking nothing further. Your latest comment gives retry and marker answers, but its first line isn't exactly
**Decision recorded.**, so I haven't treated it as a recorded decision. The change is to a workflow file and is marked host-run. Related, not duplicate: #10517 and #11024, which cover otherneeds-humanpaths.Automated triage, applied by the lanes App.
melodic-automation-lanes commentedon Nov 4, 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; its body or a criterion names .github/workflows/post-merge-demotion-alert.yml, which the issue lane cannot push (patch-protected-path); a builder session takes it; it carries host-run. 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 Nov 4, 2026
The latest triage verdict holds nothing: admission moved the issue to
status: confirmed; its comment says why.4 remaining items
kyle-sexton commentedon Nov 4, 2026
docs(pr-pipeline): add the changelog fragment for the hand-off retry
docs(loop-lane): record the hand-off retry as contract 18.0.0
fix(pr-pipeline): keep a hand-off the retry could neither send nor mark
fix(pr-pipeline): keep a marker whose issue is not listed open