docs(followup): retract an unsupported rate, restore two lost entries, keep caveats with their numbers - #322
Open
JustMaier wants to merge 2 commits into
Open
docs(followup): retract an unsupported rate, restore two lost entries, keep caveats with their numbers#322JustMaier wants to merge 2 commits into
JustMaier wants to merge 2 commits into
Conversation
…, 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>
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.
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% sensitivehad 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 onbarrier_ok=false AND reread_present=false;reread_present=falsehas occurred zero times, with zero confirmed drops ever.inconclusive_total = 0cannot 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=142mswithpromote=184.9ms) lived one entry away from the158-208msfigure it invalidates. So the freshness entry read as fact.That split is not hypothetical: the figure got laundered into an
N=10sdesign 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.mdcaused thev1.1.47checkout abort → mis-based tag. Discarding it to re-cut cleanly dropped two entries, preserved and restored here:tests/— 29 files / 178#[test]fns never build or run;tests/bulk_load_fixture_test.rsis already rotted (imports a symbolpg_syncdoesn't export) and CI has been green throughout. Coverage theatre is worse than no tests, because it's trusted./debug/memorymixes stable and noisy fields — measured spread table; two engineers drew opposite false conclusions from single samples within ten minutes.🤖 Generated with Claude Code