[mattlorimor]

Fixes #351.

#345's TestAClaimNoCutCanSeeIsRefusedBeforeItIsPricedOrAllocatedWhenEdited flaked on master in about 1 of 4 full runs: its SublimeCountMinSketch.CheckShape row allocated a few bytes past its bound. This PR finds the cause and fixes it in the test alone. Nothing in the library changes.

The cause

The row's baseline was the read of a cut just before the edited field. That cut is refused on a different path from the edited claim: Take refuses it, with "Payload ended", while the claim goes through CheckShape → RequireHolds. What a read allocates depends on what the JIT has made of its code so far. Optimised code inlines and devirtualises away hundreds of bytes, and with dynamic PGO the states in between came out higher than both. The two paths are optimised separately, so the gap between them drifts during a run.

• The failures: 82,904 bytes against a bound of 82,896 on Hold an envelope's claimed length to the bytes held before it is priced (#347) #349's branch, and 82,976 against 82,920 on master.
• The old baseline, probed alone, from cold to hot, under the default runtime, with tiering, PGO or stack allocation off, and under the segments collector: the claim came out −672 to 1,080 bytes past the cut. The bound allowed 1,024.
• Forced: a probe makes the Sublime cut's path hot, then runs the real row. It reproduced the failure byte for byte (82,976 against 82,920), 7 of 8 times on dde2413.
• Ruled out:
  • the ArrayPool trim, which drops a thread's arrays only after 30 seconds, while the forced failure took about one;
  • event listeners and first-chance handlers, of which the suite has none.

The fix

• The baseline is now the cut just after the field. The same check refuses it at the writer's claim, so it runs the same code as the edited claim.
• It's read beside the edited read, under the same budget, once just before and once just after, all in one no-GC region. The larger of the two is the bound.
• Premises: the cut's price must stop at the check, having priced what the cut before the field prices, and each read of the cut must be refused for what it lacks.
• The slack (Refusing, 1,024 bytes) is unchanged.

After the fix:

• The forced row passed 8 of 8, under both collectors.
• In 30 probed JIT states, the claim came out exactly 48 bytes past the new baseline. The old baseline ran −120 to 1,080 in the same states.
• 6 full runs, alternating the collectors: 2,668 of 2,668 each time.

Mutation: these were all killed:

• the price premises, and the read premise's message check;
• the old cut before the field, a cut a byte inside the field, and the whole payload, as baselines;
• Refusing at 0, 8,192 and 16,384;
• the envelope difference dropped, or reversed;
• 18 of the The cut sweep can't see a holds-check on a count the writer keeps small, as with DpswSketch's (#332) #344 library mutants, against the three The cut sweep can't see a holds-check on a count the writer keeps small, as with DpswSketch's (#332) #344 tests.

The survivors and their reasons are in 39d06bc's message. Two are neither killed nor equivalent: taking the smaller of the two reads, and taking the read before alone. They stay because the edited read ranged over 968 bytes across JIT states, against 976 bytes of room.

TESTING.md

The #344 bullet, updated in 3def418:

• An edited claim's read is bounded by the cut just after the field, read beside it. It says why a cut before the field won't do.
• Since A held envelope's claimed length is held only by the budget, not by the bytes held #347, it's RequireHeld in the outer price that refuses a longer nested length, not the slice. The ArgumentOutOfRangeException clause, which described the slice's check, is gone.

Found while doing this

Since #349, no test sees Slice's RequireAhead: its drop and its one-byte-laxer mutants survive the whole suite. Filed as #352.

Verification

• Clean Release build with -warnaserror: exit 0, 0 warnings.
• Full suite on 3def418: 2,668 passed, 0 failed, run by the author and again by the coordinator in a clean clone.

🤖 Generated with Claude Code

https://claude.ai/code/session_01KK3MspqAcczxT45xCfLgyx