Repository navigation
Follow-up to #1047 (slice 2): exclude concurrency-evicted runs from cum_fail and sample, and name the counted run ids in evaluate outputΒ #1054
Description
π WITHDRAWN 2026-09-01 β the premise is wrong. Do not implement.
_cumulative_healthonmaincounts onlyconclusion == "failure", in both its fast path and its pattern path.cancellednever enters the failure count, and_tier_samplecounts onlysuccess+failure. Concurrency-evicted runs were never counted towardcum_failor the sample β there is no miscount to fix.My original evidence was a bad query:
actions/runs?per_page=100returns the most recent 100 runs of all workflows, and with ~92 cancelledDev-Lead Agentruns in the window the real failures fell past the end of it, so I reported "zero failures". Querying the way the gate does (gh run list --workflow "Dev-Lead Agent" --limit 200) shows.githubhas 3 genuinefailureruns since the cut β33462228938(Run review-changes),33462008928and33462002247(Run issue). Those, not evictions, drive theREGRESSIONverdict.Implementing this would widen the selector to
failure or cancelled. Evictions get excluded again, netting zero for them, but everycancelledrun that did execute steps becomes newly counted β andmainignores those entirely today. With 92 + 84 cancelled runs in the current window that is a large, strictly-worse change.PR #1056 implemented this faithfully and is held
dev-lead:hands-off. Superseded by whatever comes out of the real question: whether those three engine-step failures are candidate regressions or belong inbenign_failure_classes.
Slice 2 of 2. Blocked on #1047 (which adds the pure _is_evicted_run predicate). Do not start until #1047 has merged β this issue only wires up what #1047 delivers.
Split out of #1047 after that issue hit the action timeout (run 33458972975, elapsed 2101s against a 2100s budget) trying to do the classifier and the wiring in one pass. Third timeout of this kind; see petry-projects/.github-private#1619.
Background
dev-lead's next->ring0 frontier is sitting on a false REGRESSION verdict β HALT + hold; recommend rollback β caused by a single concurrency-evicted run being counted as cum_fail. Full incident record and evidence in #1047. This blocks petry-projects/.github-private#1592 (D-1): repinning the fleet onto channels that promotion cannot advance would freeze every repo.
Measured frequency (17-minute window, petry-projects/.github): 13 cancelled vs 10 success, and all 13 executed zero steps. So this is not a rare edge case β the miscount fires on roughly half of all completed runs, and it scales with how busy an agent is. dev-lead is the busiest, which is exactly why it is the one that cannot promote.
Scope
A concurrency-evicted run is not evidence either way and must not influence the gate.
Acceptance criteria
-
scripts/canary-rollout.shclassifies each run with_is_evicted_run(from canary gate counts a concurrency-EVICTED run (cancelled, 0 steps executed) as cum_fail β dev-lead next->ring0 is sitting on a false REGRESSION recommending rollback; blocks #1592Β #1047) before thebenign_failure_classesfilter. Order matters: an evicted run has no failed step signature for a benign class to match (_run_signatureβ""β fails closed β counted), which is why the existing benign mechanism cannot catch it. - An evicted run is excluded from
cum_fail. - An evicted run is excluded from the source-tier
sampleβ not scored as a success. It is not evidence either way, and with ~50% eviction rates a sample floor met largely by runs that executed nothing would compute a verdict over near-empty evidence. - The
evaluateoutput names the run ids it counted and excluded. Todaycum_fail=1gives no way to see which run caused it; tracing the live false REGRESSION took ~20 minutes of manual API work. - Regression test on the real observed shape: 5 success + 1
cancelled-with-0-steps β verdict must not beREGRESSION, andcum_failmust be0. - Test that a
cancelledrun with completed steps is still counted β that case is genuinely ambiguous (a human cancelling mid-flight) and must not be laundered into "benign".
β οΈ Fixtures must use the real conclusion value
Evicted runs report run-level conclusion: "cancelled", with every job cancelled and zero completed steps. There are zero failure-conclusion Dev-Lead Agent runs in the last 100 across both repos. A fixture built as conclusion: "failure" tests a case that does not occur and would let a no-op fix pass CI. Reference runs: 33458387975 (the incident), 33460383766, 33460383602, 33460369155.
Exit criterion
After this lands, canary-rollout evaluate dev-lead on the same candidate must show cum_fail=0 and a verdict of SOAKING on dwell only β not REGRESSION. That, together with #1046, unblocks petry-projects/.github-private#1592 D-1 steps 2β3.
Related: #1047, #1046, #1049, #548, #668, #402, petry-projects/.github-private#1592, petry-projects/.github-private#1619.
Activity
don-petry commentedon Sep 1, 2026
Dev-Lead Implementation Plan
Issue: #1054 β Follow-up to #1047 (slice 2): exclude concurrency-evicted runs from cum_fail and sample, and name the counted run ids in evaluate output
Scope
Wire the pure
_is_evicted_runpredicate (delivered by #1047) into the orchestrator so a concurrency-evicted run (cancelled+ 0 completed steps) is classified before thebenign_failure_classesfilter and excluded fromcum_fail, while acancelledrun with completed steps stays counted; and add a run-id ledger toevaluateoutput.Design notes
failureruns today. Per AC1 (an evicted run reaches the benign filter, has no failed-step signature, fails closed β counted) the loop must also seecancelledruns. So_cumulative_healthnow considersfailureandcancelledruns, classifies eachcancelledrun with_is_evicted_run <conclusion> <completed_step_count>before the benign filter, excludes evictions, and counts every non-evicted run exactly as before._run_completed_step_count(steps whose conclusion issuccess/failure). Fail-closed: an unreadable run β empty count β NOT an eviction β still counted._tier_samplealready counts onlysuccess+failure, so an evicted (cancelled) run is never scored into the sample β locked with a test (AC3).evaluategains a ledger naming the run ids counted towardcum_failand those excluded as evictions (AC4).Implementation Checklist
scripts/canary-rollout.shβ add cached_run_completed_step_count <repo> <run_id>scripts/canary-rollout.shβ_cumulative_health: selectfailure+cancelled, classify_is_evicted_runbefore benign, exclude evictions fromcum_failscripts/canary-rollout.shβ add_evaluate_run_ledgerand print counted/excluded run ids incmd_evaluateTests to Write (TDD, before implementation)
cancelled-with-0-steps β verdict NOTREGRESSION,cum_fail=0cancelledrun WITH completed steps is still counted βcum_fail=1, not laundered into benignevaluateoutput names the counted + excluded run ids_run_completed_step_count: eviction shape β 0; mid-flight-cancel shape β >0; unreadable β empty (fail closed)Test Command
GH_TOKEN=dummy ./node_modules/.bin/bats tests/canary_rollout.batsdon-petry commentedon Sep 1, 2026
Dev-Lead: Implementation Complete
Plan Execution
_run_completed_step_count <repo> <run_id>(executed-step counter; fail-closed on an unreadable run)_cumulative_health: now classifies eachfailure/cancelledrun with_is_evicted_runbefore the benign filter, excluding concurrency-evictions fromcum_fail_evaluate_run_ledgerand wired it intocmd_evaluateto name the counted + excluded run idsAcceptance criteria
_is_evicted_runruns beforebenign_failure_classes(an evicted run has no failed-step signature, so benign fails closed β would be counted; the explicit eviction check catches it first)cum_failsampleβ_tier_samplescores onlysuccess+failure, so acancelledeviction is never counted as a success (locked with a test)evaluatenames the run ids counted towardcum_failand those excluded as evictionscancelled-with-0-steps β verdict SOAKING (dwell),cum_fail=0, notREGRESSIONcancelledrun with completed steps is still counted (not laundered into benign)conclusion: "cancelled"value (zerofailure-conclusion fixtures)Sample
evaluateoutput (ledger)Test Results
Files Changed
scripts/canary-rollout.sh:_run_completed_step_counthelper (+ its memo cache)_cumulative_healthselectsfailure+cancelled, classifies evictions before the benign filter, excludes them fromcum_fail; afailurerun never incurs the extra step-count lookup_evaluate_run_ledger, printed bycmd_evaluatetests/canary_rollout.bats: 8 new tests (3 unit for_run_completed_step_count, 5 orchestrator-level covering AC3βAC6 + the fail-closed/no-crash path)Notes
cancelledrun (gh run viewerror) cannot be proven an eviction, so it is counted, never excluded β the safe direction (never green-lights a bad promotion). The|| scount=""guards also stop a lookup failure from trippingset -eand aborting the gate._blocker_evidencestill listsfailure/startup_failureruns only; evictions no longer reachcum_fail, so the common case (no blocker) is unaffected. Acancelled-with-steps block is rare in practice; left as-is per scope (no test regressed).evaluate dev-leadreportscum_fail=0and a dwell-onlySOAKINGβ not the falseREGRESSION.don-petry commentedon Sep 1, 2026
Closing as not planned β premise withdrawn, see the banner on the issue body.
Short version:
_cumulative_healthcounts onlyconclusion == "failure"; evicted (cancelled) runs were never counted, so the miscount this issue set out to fix does not exist. My supporting evidence came from aper_page=100query that did not reach past ~92 cancelled runs and so showed zero failures; the gate's own query shows three real ones.PR #1056 is held
dev-lead:hands-offrather than merged._is_evicted_run(merged via #1055) is correct and tested but is now unused β harmless, and not worth a revert, but nothing should be built on it without a demonstrated miscount first.feat(#613): relocate canary-rollout engine + bootstrap into .github (β¦