A $(PXX_STABLE)-gated red should name pin lag before flakiness
Filed 2026-08-29 by frankB (Track B) from
[[regression-lib-test-lib-synapse-2]], which was auto-filed ten minutes after
the bug it reports had been fixed in master and cost a triage cycle before
that was visible.
The note as it stands
Every auto-filed ticket for a job that builds with $(PXX_STABLE) carries:
This commit CANNOT be the cause. The job builds only with
$(PXX_STABLE), and this commit moved nostable_linux_amd64/**— so the bytes that compiled it are unchanged. Look at flakiness or box load, not at the named sha; the bisect is unsound here and has been skipped.
Everything up to the last sentence is correct and genuinely useful — suppressing an unsound bisect is the right call. The last sentence is the problem: it offers two branches where the deduction has three.
| stable bytes unchanged ⇒ | |
|---|---|
| not the named commit | correct, and worth saying |
| flakiness or box load | the only alternative currently offered |
| the pin is stale relative to a fix already in master | missing — and it is the common case |
"The bytes that compiled it are unchanged" rules out the commit. It says
nothing about whether those bytes are correct, and a pinned binary is by
construction as old as the last pin. Every compiler fix that lands between two
pins produces exactly this: a $(PXX_STABLE) job that stays red at HEAD shas
for a defect HEAD no longer has.
Why it matters more than a wording nit
It re-files. In the pin-lag window the watcher raises the same finding on
every sweep, each against a fresh innocent sha — regression-lib-test-lib-synapse
then -2, with -3 due on the next sweep had the pin not moved. Each arrives
labelled "look at flakiness or box load", so each costs a triage that ends in
the same place.
And a named cause stops the next reader looking. "Flakiness or box load" is
unfalsifiable enough to absorb a real finding: it explains any red, needs no
evidence, and closes the question. The one thing it reliably prevents is
someone checking pinned's age.
Suggested change — cheap, and it is a template edit
When a job's build uses $(PXX_STABLE), add a branch before the flakiness one:
Check the pin first. This job compiles with
stable_linux_amd64/default/pinned(currently vNNN, blessed at<sha>, N commits behind origin/master). If a compiler fix landed after that pin, this job cannot see it and will stay red until the pin moves. Confirm with: build the failing source withcompiler/pascal26at HEAD — if HEAD compiles it andpinneddoes not, this is pin lag, not a regression. Only then consider flakiness or box load.
The version and blessed-sha are already known to the watcher, so the note can state the actual lag rather than the general caution — "v390, 3h and 340 commits behind" is the whole triage in one line, and it is the line that was missing here.
Verified instance
regression-lib-test-lib-synapse-2: fix 614ec6017 landed 18:47Z, ticket filed
18:57Z, job red under v390 the whole time. Same command, same corpus, same box:
red at v390, green at v391. The reader was told to look at box load.
Deprioritised 2026-09-02 — the Track T tooling backlog was cut as a pile
This ticket is not being called wrong. It was moved as part of a pile, not judged individually, and nothing here disputes its finding.
Owner decision. 73 of the 74 open track: T tickets were filed between
2026-08-31 and 2026-09-02, 58 on one day. The pile was too large to work through
and returned almost nothing, and a ticket nobody will fix does not sit neutrally
— it stays in the ranker forever at zero value, which is the argument CLAUDE.md
already makes for a terminal folder over a low prio.
Four were kept in the ranker on a purely structural test — an active umbrella or
a hard blocked-by: edge from live work:
umbrella-one-full-tier-run-with-no-red-tier,
feature-t-freebsd-image-and-runner, and the two regression-test-core-* reds
that block the umbrella.
Kept, not deleted, for two reasons: so the finding is not rediscovered and refiled from scratch by the next agent who trips over it, and so it can be pulled back if what it touches becomes load-bearing.
To revive it: move it to the owning lane's backlog, set status: backlog,
and say in the ticket WHAT CHANGED to make it matter now. Restoring it because it
reads well is how the pile comes back.