Skip to content

docs(followup): retract an unsupported rate, restore two lost entries, keep caveats with their numbers - #322

Open
JustMaier wants to merge 2 commits into
mainfrom
docs/followup-corrections
Open

docs(followup): retract an unsupported rate, restore two lost entries, keep caveats with their numbers#322
JustMaier wants to merge 2 commits into
mainfrom
docs/followup-corrections

Conversation

@JustMaier

Copy link
Copy Markdown
Contributor

Docs-only. No code, no behaviour change. Three corrections, one root cause: a number outliving the evidence for it.

1. Retracts a rate that was quoted from n=2

The entry Verifier orphan detection is only ~50% sensitive had the retracted number in its title. The "~50% / ~1-in-2" barrier-timeout rate was n=2; as n grew it fell (1/2 → 2/5 → 2/6 → 2/7) toward ~25-30%, and no n worth quoting exists yet.

Rewritten with no rate at all. The argument never needed one — a barrier that misses even 1-in-4 publishes is a defect, and the exact rate changes nothing about the fix. Quoting one is how it spread; ava (who produced the figure) retracted it herself.

2. Removes advice the counter cannot support

The entry said to size the work from inconclusive_total's rate. It can't. That counter fires only on barrier_ok=false AND reread_present=false; reread_present=false has occurred zero times, with zero confirmed drops ever. inconclusive_total = 0 cannot distinguish "the barrier hid nothing" from "there was nothing to hide" — an ambiguous quiet counter, unresolvable by waiting, because the resolving event has never occurred. It is strictly dominated by a T+10s re-check (~20× the margin, no stall), so v1.1.49 deletes it.

Also records the finding that reshaped the v1.1.49 plan: deleting the barrier is a SWAP, not a subtraction. The ring is a bare VecDeque<u32> with no time dimension, so a naive "just requeue" yields ~0 delay — a hot re-check loop that reads pre-publish state exactly like the barrier and re-drives false drops. The scheduler is the work.

3. Moves a caveat next to the number it qualifies

The [flush-slow] promote= caveat (the fields don't sum: total=142ms with promote=184.9ms) lived one entry away from the 158-208ms figure it invalidates. So the freshness entry read as fact.

That split is not hypothetical: the figure got laundered into an N=10s design justification it cannot support — by me, hours after I wrote the caveat. A caveat that doesn't travel with its number isn't a caveat. The 93-98% timeout rate is unaffected: it's counted directly (13/14, 112/114) and never rested on the promote field.

Also: restores two entries lost in the v1.1.47 tag recovery

A dirty FOLLOWUP.md caused the v1.1.47 checkout abort → mis-based tag. Discarding it to re-cut cleanly dropped two entries, preserved and restored here:

  • CI never compiles tests/ — 29 files / 178 #[test] fns never build or run; tests/bulk_load_fixture_test.rs is already rotted (imports a symbol pg_sync doesn't export) and CI has been green throughout. Coverage theatre is worse than no tests, because it's trusted.
  • /debug/memory mixes stable and noisy fields — measured spread table; two engineers drew opposite false conclusions from single samples within ten minutes.

🤖 Generated with Claude Code

JustMaier and others added 2 commits July 15, 2026 13:15
…, keep caveats with their numbers

Three corrections, all the same root: a number outliving the evidence for it.

1. RETRACT "~50% sensitive" / "~1-in-2" barrier-timeout rate. It was n=2. As n
   grew it fell (1/2 -> 2/5 -> 2/6 -> 2/7) toward ~25-30%, and no n worth quoting
   exists yet. The entry's TITLE was the retracted number. Rewritten with no rate
   at all: a barrier missing even 1-in-4 publishes is a defect, and the exact rate
   never changed the fix. Quoting one is how it spread.

2. The rewritten entry also drops "size the work from inconclusive_total's rate" —
   it cannot. That counter fires only on barrier_ok=false AND reread_present=false;
   reread_present=false has occurred zero times, with zero confirmed drops ever, so
   0 cannot distinguish "hid nothing" from "nothing to hide". It is strictly
   dominated by a T+10s re-check. v1.1.49 deletes it. Records that the barrier
   deletion is a SWAP, not a subtraction: the ring has no time dimension, so a naive
   requeue yields ~0 delay and re-drives false drops.

3. Move the [flush-slow] promote= caveat NEXT TO the number it qualifies. It lived
   one entry away, so the freshness entry read 158-208ms as fact. That split is
   exactly how the figure got laundered into an N=10s justification it cannot
   support. The 93-98% timeout rate is counted directly (13/14, 112/114) and does
   not depend on it.

Also restores two entries lost when a dirty FOLLOWUP.md was discarded during the
v1.1.47 tag recovery: the CI-never-compiles-tests/ gap (29 files / 178 tests
invisible, one already rotted) and the /debug/memory stable-vs-noisy spread table.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…the band that judged it was contaminated

Two additions to the PERF/promote entry, both from prod (ava):

1. SECOND INDEPENDENT CONFIRMATION that [flush-slow] promote= is not a
   per-cycle cost: two consecutive breakouts 2 SECONDS APART both reported
   promote=256.3ms — identical to the decimal. A real per-cycle cost does not
   repeat exactly across consecutive cycles. This is a different route to the
   same conclusion as the total=142ms/promote=184.9ms contradiction. Two
   independent routes to one defect => treat the field as broken, not suspicious.

2. The band used to judge flush outliers was CONTAMINATED: `grep 'total='`
   also matches `post_apply_total=`, mixing a 100-900ms series with a 3-26ms
   one (34 values from 17 lines). Anchored on `[flush-slow] total=`:
   p95=158ms vs the contaminant's max=26ms. The tell was min=1 in a band of
   ~100ms values.

   The 400ms threshold SURVIVES the correction — p95=158 is comfortably
   outside it, so the 456/485/524/583/897ms events are genuine outliers — but
   it survives BY LUCK: the pollution landed where the sort didn't move the
   percentiles much. Right-for-the-wrong-reason is indistinguishable from
   right until you check. Recorded so the next reader verifies a grep band
   contains only the series they think it does before trusting a percentile.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant