backlog(#340): the merge-queue cost, re-derived — and two false statements in the item itself - #143
Merged
Conversation
…ments in the item itself
The #340 filing was agreed to need cost evidence. The hand account it was to be
built from ("#132 took four full CI cycles to land, none from a failure — green ->
main moved -> rebase, x3, ~80 min of runner time for a change correct on the first
pass") was wrong in every load-bearing figure, so this re-derives all of it from the
Actions API instead of relaying it.
What #132 actually did: nine CI runs / ten attempts across eleven head moves in a
3h28m window; two attempts failed on real defects (one on the head it opened at, so
it was not correct on the first pass — it opened at one commit and merged at five);
four runs cancelled in flight by cancel-in-progress; five head moves were rebases,
four of them onto a main tip that had landed 1-14 min earlier. Cost 212.7 min run
wall-clock / 442.5 min job wall-clock — quantities that differ by 2.08x, so the unit
is load-bearing. No billable figure exists: /timing reports 0 billable ms (self-hosted).
Two statements already in the item were false and are corrected:
- "A hand-coordinated merge freeze ... *did* hold main still for a full window."
It did not. main advanced four times between #119's first fully-green head and
its merge, one of them 8m26s after the freeze was recorded in a work claim.
- "#119 still failed" / "the bounds that actually killed #119" reads as the PR
dying. #119 merged at 2026-08-02T01:45:00Z, 12h15m after arming.
The caveat is stated level with the cost, per the standard this repo keeps
violating. Notably the overnight serialization is NOT evidence hand coordination
worked — it is entailed by strict + a 20-25 min suite — and strict does not always
serialize (#110/#111 merged 24s apart; mechanism not established). Also measured:
no workflow carries a merge_group: trigger, so zero of the 13 required contexts
would report on a queue ref, which makes Proposed step 2 a precondition rather than
a follow-up.
Adds the measurement-cost linkage to #344: supersession-and-re-run produces
multi-attempt runs, and the default actions/runs/{id}/jobs endpoint returns only the
latest attempt, so failed earlier attempts vanish from any duration table built from
it — at exactly the tight end where a margin is decided.
#344's own figures are untouched; another session holds that item.
wshallwshall
enabled auto-merge (squash)
August 2, 2026 13:20
…t was imprecise
Two amendments from peer review, both of which improve on what I wrote.
1. My measurement-cost paragraph conflated two different prunings. Corrected by
the ci-margin-correction session, who hit the same trap from the other side and
re-measured with ?filter=all. The precise statement:
- filtering on JOB conclusion deletes job-cancelled/step-succeeded rows, which
are the tightest by construction;
- the default latest-attempt view hides FAILED earlier attempts. It does NOT
move a step-success maximum -- so my implication that it changes the margin
was wrong. What it hides is that the sample is RIGHT-CENSORED: the largest
observable step is the largest that FIT under the cap.
Keying on the step's own conclusion (not the job's) and reading ?filter=all are
two separate fixes for two separate defects. Still no #344 figure is quoted here.
2. Adds the protocol cost, relayed independently by two sessions and assembled by
sandbox-codec. It is the strongest argument in the item and is not a throughput
argument: with no queue, sessions invent an ordering ritual, and the ritual is
less reliable than the mechanism it replaces. The self-reported instance -- a
session promising not to jump the queue while its own PR had auto-merge armed --
is already named as a failure mode in WORKTREES.md, which that session had read
about this very freeze hours earlier.
Also: re-read the open-PR set nine hours after the first measurement. 15 open, 10
armed, still 0 CLEAN. Membership churns; the condition has never lifted.
Removes a "20-25 min" suite duration I restated twice without deriving it -- the
What section already states it once, which is where it belongs.
wshallwshall
added a commit
that referenced
this pull request
Aug 2, 2026
…ide (#144) Follow-on to #143, which merged before this measurement existed. Adds the one argument #340 was missing, and it is a better one than the cycle-count case. Measured 2026-08-02T13:41Z, re-derived here rather than relayed: open=14 armed=9 armed_and_inert=6 armed_and_CLEAN=0 #142 BEHIND #139 BEHIND #128 BEHIND #101 BEHIND #96 BEHIND #71 DIRTY Two-thirds of the armed PRs in this repo cannot land, and NOT ONE armed PR was CLEAN. #71 is armed and DIRTY, so it can never land at all. Why this belongs in the item: everything else in #340 is an efficiency argument, and an efficiency argument has a "then be patient" answer. This one does not. Every session here reads autoMergeRequest != null as "this will land" -- I said exactly that about my own PR an hour before measuring this -- when for six of nine it means "this waits until a human runs gh pr update-branch", with nothing reporting the difference. That is the ADR 0158 defect class (a green signal that means nothing) caught live rather than in retrospect. ADR 0158 is referenced by number, not linked: it is not on main yet. The measurement came out of the sandbox-codec session's queue claim, checked by the announce-hook session, and the connection to 0158's class is sandbox-codec's. Both routed it to me rather than writing it, since #340 is claimed here. Re-derived independently before writing; their figures and mine agree exactly.
This was referenced Aug 2, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
BACKLOG #340 was filed with its cost evidence agreed but not written. The hand account it was to be built from was wrong in every load-bearing figure, so this re-derives all of it from the Actions API rather than relaying it.
The claim under test, inherited via a handoff: "#132 took four full CI cycles to land, none from a failure — green → main moved → rebase, ×3. ~80 min of runner time for a change correct on the first pass."
What #132 actually did, from
actions/runs,actions/jobsandcommits:The two quantities differ by 2.08x, so the unit is load-bearing. No billable figure exists —
/timingreports 0 billable ms on every run (self-hosted legs), so none is quoted.Two statements already in the item were false and are corrected:
mainstill for a full window." It did not —mainadvanced four times between ADR 0154 increment B: synchronous captured-downstream reply (reply_from) #119's first fully-green head and its merge, one of them 8m26s after the freeze was recorded in a work claim.The caveat is stated level with the cost, since filing an overclaim inside the ticket about overclaiming would be its own instance. Chiefly: the overnight serialization is not evidence that hand coordination worked — it is entailed by
strict = trueplus a 20–25 min suite either way — andstrictdoes not always serialize (#110/#111 merged 24s apart; mechanism explicitly not established).One new actionable finding: no workflow carries a
merge_group:trigger, so zero of the 13 required contexts would report on a queue ref. That makes Proposed step 2 a precondition, not a follow-up — enabling the queue first would wedge every open PR.Also records the measurement-cost linkage to #344: supersession-and-re-run produces multi-attempt runs, and the default
actions/runs/{id}/jobsendpoint returns only the latest attempt, so failed earlier attempts vanish from any duration table built from it — at exactly the tight end where a margin is decided.Scope:
docs/BACKLOG.mditem #340 only. #344's figures are untouched — another session holds that item. Banner invariant re-checked (264 items, one status each); ledger gate passes.Every figure above was produced under adversarial verification (independent refutation passes per claim, on units/population/overclaim lenses) rather than by a single author, because the six retractions in this repo last night were each caught by a peer and never by the author.