Repository navigation
perf(lanes): shorten work-resolve-issue's stranded re-fire backoff for transient failure classes #12635
Description
Refs: #12284
Problem
The #12284 findings name work-resolve-issue as the largest lane: 694 run-hours in 7 days, 25% failed or cancelled. Lever 3 of the 2026-11-01 lifecycle baseline still applies: a stranded run whose failure class is transient waits the full re-fire backoff before it is tried again, so the issue sits idle.
Fix
Shorten the stranded re-fire backoff for transient failure classes only, from configuration. Leave turn-cap-restarts as it is (pr-pipeline.yaml:958).
Done when
- A stranded work-resolve-issue run with a transient failure class is re-fired after a shorter, configured backoff; other classes keep today's backoff.
- The backoff per class is read from configuration, not hard-coded.
- The median idle time from a transient failure to the re-fire is measured for 7 days before and after, and posted here.
Filed by the issue-triage session from #12284's findings.
Activity
github-actions commentedon Nov 3, 2026
Proposed work class: work-class: scoped
Basis: automated intake triage; the lanes App applied this class.
Size: Small
Complexity: Medium
Uncertainty: Knowable
Flags: none
Blocked by: none
Understood: a stranded work-resolve-issue run that failed with a transient class should be re-fired after a shorter backoff. The backoff should be set per class in configuration, and other classes and
turn-cap-restartskeep today's values. The 7-day before/after median-idle measurement needs time to pass and can't be done in a single run, so it will need follow-up after the change merges. I found no duplicates among the open issues. Reading the current re-fire configuration will settle which classes count as transient.Automated triage, applied by the lanes App.
github-actions commentedon Nov 3, 2026
github-actions commentedon Nov 3, 2026
melodic-automation-lanes commentedon Nov 3, 2026
The lanes App's pull request #12644 for this issue was closed without merging. work-unblock removed
status: readyandagent-ready, so the hourly triage sweep sends it back to intake triage, which decides what work is left and admits it again.github-actions commentedon Nov 3, 2026
The triage sweep dispatched intake triage for this issue (dispatch 1; 2 runs that reach intake, or 6 dispatches, hand it to a maintainer).
melodic-automation-lanes commentedon Nov 3, 2026
Not admitted to the issue lane: its done-when asks for what an unattended lane run cannot perform: item 3 (tracker-output: "The median idle time from a transient failure to the re-fire is measured for ..."); recommended split: keep the other items here as the admissible issue and move these to a child issue for the host queue (
host-run); merged pull request #12804 names it withRefs:after its newest decision or refinement comment, so its work may already be done: close the issue if it is, or post a comment whose first line is**Decision recorded.**saying what is left, which sends it back through intake. 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 3, 2026
The latest triage verdict holds nothing: admission moved the issue to
status: needs-decision; its comment says why.kyle-sexton commentedon Nov 4, 2026
Delivered: closing as completed.
Agent choice, not an owner answer.
What #12804 (ea71ee1, merged 2026-11-03T16:07Z) delivered, checked on
origin/main:limits.stranded-backoff-hourssetsno-run: 1,failed-mint: 1andkill-switch: 1(the transient causes, where no model ran) and keepsno-report: 3andfailed-again: 3(docs/conventions/pr-pipeline.yaml:1085-1090).docs/conventions/pr-pipeline/pr-pipeline.schema.json:146; work-unblock readslimits["stranded-backoff-hours"]per cause (.github/scripts/work-unblock/label-unblocked.mjs:1719).Carried: body item 3, the 7-day before-and-after measurement, moves to host-run #13073. It is a measurement over time, which no lane run can perform, and #12804's own commit lists it as not done. The after window opened at the merge, so #13073 finishes no earlier than 2026-11-10T16:07Z. Nothing else is left on this issue.
kyle-sexton commentedon Nov 4, 2026
Closing as completed: items 1-2 delivered by #12804; the 7-day measurement is carried to #13073 (record above).