--- name: duration-over-a-timeout-is-not-a-stretch description: "A duration exceeding a known deterministic timeout by ~a normal run is a path that TOOK the timeout, not a slow path — subtract the constant before ever calling it a stretch" metadata: node_type: memory type: feedback originSessionId: ce69296f-597d-40b9-ac2f-8ebdca841a43 modified: 2026-08-19T20:34:30.158Z --- A failing run at **33.650s** against the same cell's **3.530s** passing run looked like a 10× stretch, so I called it one. `RECONNECT_WINDOW` is `Duration::from_secs(30)` (`rc.rs:2444`). **33.650 − 30 = 3.650s. Residual against the passing run: 0.120s.** It was a normal-speed run that spent a deterministic timeout — never a slow run at all. **Why:** I built the framing on a bare duration comparison (slow case vs fast case) and made it the HEADLINE of a specimen packet, so it propagated as the thing to explain. Three agents hunted load because of it: doyle recorded an x40 ER sweep as a candidate contributor, I recorded my own release build contention, todlando began recording heavy-process counts before and after every run in a battery for me, and hertz spent **92 runs** (12 quiet, 16 simultaneous, four x64 waves) plus a 500ms H1 gap probe killing the load hypothesis. One subtraction would have refuted it before any of that started. The truth was product-side: a missing terminal `Exit` classified as EOF ⇒ `PumpEnd::Severed`, which *deterministically* spends the 30s window before `ReconnectGaveUp`. **How to apply:** before calling any duration a stretch, find the timeouts on that path and subtract them. The discriminator is **subtraction against the constant**, never comparison against the fast case — those two look identical and answer different questions. Tell: a residual that lands within noise of a normal run means a timeout was spent, and the question becomes *what failed to arrive*, not *what ran slowly*. Two corollaries earned in the same window: - **A timeout-spent failure and a resource-starvation failure are different KINDS, not merely different signatures.** This is why load could not reproduce it at any level — hertz's set included a **34.957s PASS**, same duration class as the fail, opposite verdict, which proves duration was never the variable. It is also the sharper reason the cell's `FLAKE-LEDGER` entry (a 240s starvation timeout) did not cover it: I refused the match on signature and was right for a weaker reason than the real one. See [[golden-respin-test]]. - **Naming a mechanism in a dispatch narrows it.** doyle's referral trigger said "the product's reconnect grace", which mapped to one hypothesis; the confirmed product-side candidate was a different one (broker suppressing `KIND_EXIT` unless waiter status is `Ok`). A dispatch that names a mechanism rather than a SIDE can send a product defect back through a test lane. Same family as [[a-predicate-without-its-tool-is-not-evidence]] and [[stale-carried-forward-sentence]] — a number carried forward as a characterization rather than re-derived at the point it drives a decision. --- **Second instance, 2026-08-28 (v0.64.0 cut) — and I did not apply my own rule.** Thin `ci.yml` red at a golden-GREEN sha: `spt-daemon servicehost::tests::a_path_verified_orphan_is_reaped_and_confirmed_by _a_post_kill_read` failed in **3.649s** (`KillFailed(32896)` where `Killed` was asserted, `servicehost.rs:2512`) while the SAME cell passed in golden's Windows Phase A at the SAME sha in **0.106s**. I referred it to doyle with the duration gap framed as a **34x asymmetry** — a comparison against the fast case, which is precisely the move this file says looks identical to the right one and answers a different question. doyle did the subtraction instead: `awaits_death(pid, KILL_CONFIRM_MS = 2000)`, so **3.649 − 2.000 = 1.649s** of spawn/verify overhead — the kill was ISSUED and the confirm window was SPENT, at budget. Not a slow run. What the subtraction then bought that the comparison could not: the product treats `KillFailed` as **retryable by design** (identity record kept, next sweep retries, `servicehost.rs:687`) while the TEST asserts first-sweep `Killed` — so the cell binds tighter than the contract it pins and is load-fragile by construction. Both readings were honest readings of a 2s bound under different box states (the thin job started 09:00:13Z, ~2s after the Windows release build stopped saturating that box). Filed to hertz as a test-lane rider; product never implicated. Two things to carry: - **Having the rule is not applying it.** The referral was still correct — I measured both sides, refused to call it a flake, and named the duration as a place to look rather than a verdict — but the constant was one grep away and I handed the subtraction to someone else. Tell: whenever a pass/fail duration pair is about to become the headline of a referral, grep the path for its timeout constants BEFORE sending. - **A pass/fail pair at one sha is the strongest possible invitation to subtract**, because the tree is held fixed: the only remaining variables are the box and the clock. See [[identical-readings-across-opposite-outcomes-indict-the-meter]] for the inverse shape.