Filed unassigned and ungraded by the #12538 dev (session session_01PfaSTikked61BkcsB5Rn69) while re-deriving the hold-time distribution that card asked for. ⛔ Not fixed there — a different defect from the wait budget, and repairing it means choosing between the label and the recorded value.
Measured
mode_run takes the depth AFTER minting its own ticket:
ARRIVAL_DEPTH="$(queue_live | wc -l | tr -d ' ')"
and a run that ACQUIRES removes its ticket at that moment (rm -f "$TICKET" right after HOLDING=1), so the holder is not in queue_live either. The recorded number is therefore the caller plus the waiters ahead of it, and its floor is 1.
mode_report prints it under:
queue depth on arrival (waiters already ahead):
Read on this container 2026-08-27, 25 records: depth p50=1 p90=1 max=1, against waited n=5 max=3s and zero queue-timeout records — i.e. a completely uncontended population presenting as "1 waiter already ahead" on every single row.
Why it matters
This is the column a reader uses to decide whether the lock is contended, and it reads one waiter too many in exactly the case where the answer is "nobody". The comment on the field states the intended meaning correctly ("N of us were waiting"), so the record is right and only the presentation is wrong — but a reader has no way to tell which of the two is off.
The choice this needs
- Relabel (
including yourself, or subtract 1 in mode_report) — keeps every existing record comparable. - Record waiters-ahead instead — reads better, but silently changes the meaning of a field across the boundary, which is the mixed-population hazard
--report already warns about for command-exit.
Refs
Generated by Claude Code
Filed unassigned and ungraded by the #12538 dev (session
session_01PfaSTikked61BkcsB5Rn69) while re-deriving the hold-time distribution that card asked for. ⛔ Not fixed there — a different defect from the wait budget, and repairing it means choosing between the label and the recorded value.Measured
mode_runtakes the depth AFTER minting its own ticket:and a run that ACQUIRES removes its ticket at that moment (
rm -f "$TICKET"right afterHOLDING=1), so the holder is not inqueue_liveeither. The recorded number is therefore the caller plus the waiters ahead of it, and its floor is 1.mode_reportprints it under:Read on this container 2026-08-27, 25 records:
depth p50=1 p90=1 max=1, againstwaitedn=5 max=3s and zeroqueue-timeoutrecords — i.e. a completely uncontended population presenting as "1 waiter already ahead" on every single row.Why it matters
This is the column a reader uses to decide whether the lock is contended, and it reads one waiter too many in exactly the case where the answer is "nobody". The comment on the field states the intended meaning correctly ("N of us were waiting"), so the record is right and only the presentation is wrong — but a reader has no way to tell which of the two is off.
The choice this needs
including yourself, or subtract 1 inmode_report) — keeps every existing record comparable.--reportalready warns about forcommand-exit.Refs
os-verify-lock's 540s wait budget is shorter than a single legitimate hold — a compliant caller times out systematically, not occasionally #12538 — where this was measured (the wait budget vs. the hold time)os-verify-lockserialises locked heavy jobs but NOT gate scripts — so every timing card measures a contended box while believing the lock gave it an idle one #12528 — the lock's coverage boundaryGenerated by Claude Code