Repository navigation
fix(pr-pipeline): the mint-failed re-fire for resolve-issue matches a step the read runner does not have #9102
Description
Problem
didNoWork in .github/scripts/work-unblock/label-unblocked.mjs re-fires a resolve-issue run whose lane token mint failed by matching a step named "Request the lane token" under resolve-issue / run. resolve-issue calls pr-run-activity-read.yml, which has no such step (its broker step is "Ask the broker whether the lane may run"); "Request the lane token" exists only in pr-run-activity-write.yml. So a resolve-issue run whose broker refused or failed is never re-fired by that path. It fails toward not re-firing, so it is a stuck-issue risk, not a security one. Found while building #9097 (Security & Cost agreed).
Fix
Match the read runner's broker step (or the job/step names #9097's workflow-shape test pins) for resolve-issue, keep "Request the lane token" for the write-runner path, and extend that test to cover the mint-failed shape.
Activity
github-actions commentedon Oct 22, 2026
Proposed work class: work-class: scoped
Basis: automated intake triage; a maintainer confirms or changes it.
Size: Small
Complexity: Low
Uncertainty: Known
Flags: none
Blocked by: none
#9102 (comment)
The decision settles the open questions. The remaining work is to class a resolve-issue broker-check failure that isn't a kill-switch refusal as
mint-failed, add tests for it, and update the two code comments.Automated triage. A maintainer reviews it.
github-actions commentedon Oct 26, 2026
The triage sweep dispatched intake triage for this issue (attempt 1 of 2).
melodic-automation-lanes commentedon Oct 26, 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 26, 2026
The latest triage verdict holds nothing: the issue is at
status: ready.melodic-automation-lanes commentedon Oct 26, 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: A resolve-issue run whose broker-check step "Ask the broker whether the lane may run" failed for a non-kill-switch reason is classed mint-failed and re-fired, with the write runner's MINT_STEP kept and the workflow-shape test extended.
Related work
Open questions
RECOMMENDED: Yes: when a resolve-issue broker-check job fails at BROKER_STEP and the refusal is not kill-switch, class it mint-failed so it is re-fired under the existing failed-mint bound, and add a test for that shape. Basis: .github/scripts/work-unblock/label-unblocked.mjs:791-811
RECOMMENDED: Yes, re-fire any non-breaker broker-check failure; #9498 can later stop the refusal itself. Basis: judgment
RECOMMENDED: Owner should check #8446; I could not open it and judge it a related issue, not a duplicate, from its title. Basis: 8446
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 and Issue Triage sessions (2026-10-25), deciding the open items below on the facts:
No owner ledger (
.work/*/interview-checklist.md,.work/gh-monitor-owner-decisions/) names this issue.Already on main (
.github/scripts/work-unblock/label-unblocked.mjs):BROKER_STEP(label-unblocked.mjs:209-210).MINT_STEPstays the write runner's step (:199-200).BROKER_STEPis read (:792), and a kill-switch refusal there is classedbreakerand re-fired (:802-804), from fix(pr-pipeline): class a kill-switch refusal as a breaker trip in work-unblock #9946 and fix(pr-pipeline): count a green kill-switch stop as a breaker trip #10160.label-unblocked.test.mjs:2291-2301). ABROKER_REFUSEDjobs fixture exists (label-unblocked.test.mjs:2011-2028).Remaining gap: a broker-check failure for any other reason, or one whose log names no reason, falls through. The read runner has no
MINT_STEP, somintingis null (:793), and no class matches (:803-811). The code comment says so: "A broker-check refusal for another reason, or one whose log gives none, is none of these" (:767). That run is never re-fired, which is the stuck-issue risk the body names.Questions from intake's refinement (#9102 (comment)):
Decided: Yes. The body's problem is that "a resolve-issue run whose broker refused or failed is never re-fired by that path", and that still holds for every reason but the kill switch. Such a run is classed
mint-failed, so it is re-fired under the existing failed-mint bound: up tolimits.limit-stops-per-issuetimes per version of the lane workflow files, then on the stranded backoff (label-unblocked.mjs:91-99). No new bound or class is added. A kill-switch refusal staysbreaker.Decided: Yes. A re-fire starts a fresh run on main's workflow files (
label-unblocked.mjs:84-89), which is what a stale-file refusal needs. The broker is asked again on every run, so a re-fire passes no gate it would refuse. fix(pr-pipeline): stop broker workflow-modified refusals failing work-resolve-issue runs #9498 (raw/full/9498.json, open) asks why those refusals happen and does not conflict.Decided: No. pr-pipeline: re-fire PR-lane runs lost to a broker 5xx or token 403 #8446's body covers PR-lane runs and
refire-refused.mjs("The issue lane re-fires runs refused at the token step ... but PR lanes do not",raw/full/8446.json). This issue is the issue lane'slabel-unblocked.mjs.Acceptance criteria:
didNoWork, a resolve-issue job that failed atBROKER_STEPfor a reason other than the kill switch, or whose log gives no reason, is classedmint-failed. The write runner'sMINT_STEPmatch is unchanged..github/scripts/work-unblock/label-unblocked.test.mjsuses theBROKER_REFUSEDjobs with a non-kill-switch refusal log, and with no readable log, and assertsmint-failed. The existing kill-switch test still assertsbreaker.label-unblocked.mjs:91-93and:767say that a non-kill-switch broker-check failure is re-fired asmint-failed.