You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
fix(pr-pipeline): stop fix-docs redispatching a head whose run emitted an empty head #9247
After #9223, a fix-docs run whose run job emits an empty head with post-decline: false posts nothing, the same as a decline. fix-docs-dispatch remembers only whether a check run exists for the head (.github/scripts/pr-unblock/fix-docs-dispatch.mjs:113, :118). A run job that ran its model leg and then emitted an empty head therefore gets the head redispatched on every cycle, spending the role's API key each time. The spend is bounded by the prepaid balance, since auto-reload is off, so no bill results, but the credits are wasted.
Options:
Decide "declined" from needs.<leg>.result, which the run job cannot set, not from the run job's outputs.
Cap fix-docs redispatches per head.
Found by the security review of #9223 at 41de6a7 (rated LOW, not a merge hold).
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
Decision recorded.
The owner answered in the Refinement and Issue Triage sessions (2026-10-25), deciding the open items below on the facts:
[quote truncated; the full decision is at https://github.com//issues/9247#issuecomment-6426030928]
The recorded decision settles the open questions: it picks the per-head cap, counting only runs whose broker-allowed job succeeded, with a test in the fix-docs-dispatch test file. Nothing further is asked. This is a bounded fix to the existing dispatcher, so I've triaged it as a Bug, priority medium.
Released for re-triage under the owner's 2026-10-26 rule: a person is involved only for "1. A change in original intent/vision 2. Something comes up during implementation ... that alters intent/vision or the primary design 3. If there is a HIGH/CRITICAL security issue". None applies here, so the hold label came off and intake triage runs again now.
To hold this issue again, add needs-human (or status: needs-decision) and name which of the three applies.
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 commented on Oct 26, 2026
The work-resolve-issue run that agent-ready started failed or was cancelled before it reported, or it stopped or the token broker refused it because its workflow files differ from main's. work-unblock removed and added agent-ready back 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.
The work-resolve-issue run that agent-ready started failed or was cancelled before it reported, or it stopped or the token broker refused it because its workflow files differ from main's. work-unblock removed and added agent-ready back 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.
Activity
github-actions commentedon Oct 22, 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
The recorded decision settles the open questions: it picks the per-head cap, counting only runs whose broker-allowed job succeeded, with a test in the fix-docs-dispatch test file. Nothing further is asked. This is a bounded fix to the existing dispatcher, so I've triaged it as a Bug, priority medium.
Automated triage, applied by the lanes App.
kyle-sexton commentedon Oct 26, 2026
Released for re-triage under the owner's 2026-10-26 rule: a person is involved only for "1. A change in original intent/vision 2. Something comes up during implementation ... that alters intent/vision or the primary design 3. If there is a HIGH/CRITICAL security issue". None applies here, so the hold label came off and intake triage runs again now.
To hold this issue again, add
needs-human(orstatus: needs-decision) and name which of the three applies.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.4 remaining items
melodic-automation-lanes commentedon Oct 26, 2026
The work-resolve-issue run that
agent-readystarted failed or was cancelled before it reported, or it stopped or the token broker refused it because its workflow files differ from main's. work-unblock 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.melodic-automation-lanes commentedon Oct 27, 2026
The work-resolve-issue run that
agent-readystarted failed or was cancelled before it reported, or it stopped or the token broker refused it because its workflow files differ from main's. work-unblock 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.