Retire a disclosed weakening that no longer exists

The B4 harness documented `max_index_runs` as a ceiling reached by
refusal: B1's slice sealed no delta layer into an `IndexRun`, so `submit`
returned `NotImplemented` after exactly that many group publications, and
a driver needing more had to raise the ceiling to run at all. That was
recorded as a disclosed weakening because it configured around a missing
deliverable rather than a tuning choice.

Every part of it is now false. Sealing is implemented, the ceiling is
drained by sealing rather than reached by refusing, and no
`NotImplemented` refusal remains in the engine's production paths. A
45-second soak at the default published 5,192 groups -- 81x the ceiling --
at a flat rate. Leaving the disclosure in place understates the store in
its own evidence.

The same claim appeared in `store-bench.rs`'s `configured_ceilings`
comment and in the plan's note on why `max_index_runs` became a required
bundle member; both now say the run seals against the ceiling.

`scripts/check-phase1.sh` was not prose. Its crash-matrix pending-row
check was guarded on B1 having landed, proxied by `engine.rs` no longer
mentioning `NotImplemented`. B1 landed and the token survived in a module
doc and in two tests asserting an error is *not* one, so the grep matched
and the check silently stopped running. Zero pending rows made that
harmless, but a gate condition that had inverted is worth more than the
row it was guarding. The transitional guard is gone and the check is
unconditional.

`CONTENTION_MAX_INDEX_RUNS` is removed rather than aliased: the driver
reaches a genuinely lost committed-root CAS after 11 and 12 transactions
against a ceiling of 64, reproducibly, and the row's test panics rather
than passes if the failpoint never fires. The old note measured a worst
case that could exceed 64, which no longer refuses either.

`bench/result-schema.json` is untouched. Nothing in-tree emits
`raised_because_index_sealing_unimplemented` now, but it remains a valid
declaration for a bundle that did raise the ceiling, and retiring it is a
compatibility decision of its own.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01JGdH5V43XWnj1PdHqiPktQ
This commit is contained in:
Levi Neuwirth 2026-08-09 18:13:14 +02:00
parent ee886f6138
commit 660b4c74d0
No known key found for this signature in database
4 changed files with 26 additions and 28 deletions

View File

@ -2455,7 +2455,9 @@ pub fn assemble_bundle(
// The `u32` from the `StoreOptions` the store was opened with,
// carried through the run rather than `ENGINE_MAX_INDEX_RUNS`
// written out a second time. It is the ceiling this workload
// genuinely reaches: `submit` refuses `NotImplemented` at it.
// genuinely reaches -- the fan-out trigger fires on it and the
// run seals against it, which is the steady state a P2 number
// has to be measured in.
(
"max_index_runs".into(),
jint(i128::from(inputs.observations.configured_max_index_runs)),

View File

@ -133,29 +133,22 @@ impl CommitEvidenceSigner for CountingSigner {
}
}
/// `StoreOptions::max_index_runs`, the ceiling this slice reaches soonest.
/// `StoreOptions::max_index_runs`, at the value a deployment runs.
///
/// Publishing a group adds one in-memory index delta layer, and B1's slice
/// seals none of them into an `IndexRun` — deliverable 1 refuses by name. So
/// `submit` refuses `NotImplemented` after exactly `max_index_runs` group
/// publications for the life of an engine, root-wide, whatever the workload.
/// At the shipping default of 64 that is 64 commits.
/// **The weakening this note used to disclose is gone.** It said that B1's
/// slice sealed no delta layer into an `IndexRun`, so `submit` refused
/// `NotImplemented` after exactly `max_index_runs` group publications and a
/// driver needing more had to raise the ceiling to run at all. Sealing is
/// implemented: the ceiling is drained by sealing rather than reached by
/// refusing, no `NotImplemented` refusal remains in the engine's production
/// paths, and a 45-second soak at this value published 5,192 groups — 81× the
/// ceiling — at a flat rate.
///
/// The single-row driver leaves the default alone: three submits per row is
/// nowhere near it, and a row driven under a non-default ceiling would be a row
/// driven against a store nobody ships. The contention driver raises it,
/// because it must publish groups until two of them collide and the collision
/// is not on a schedule. **That is a disclosed weakening**: the raised value is
/// a real configuration, not a bypass, but it configures around a missing
/// deliverable rather than around a tuning choice, and it is the same
/// unimplemented seal that caps the benchmark.
/// So the default is what every driver here uses, which is the point: a row
/// driven under a non-default ceiling is a row driven against a store nobody
/// ships.
pub const DEFAULT_MAX_INDEX_RUNS: u32 = 64;
/// Enough that the collision search is never the thing that ends the run.
/// Measured: the failpoint fires within 6 to 64 group publications, and the
/// eight repository creations consume eight of them.
pub const CONTENTION_MAX_INDEX_RUNS: u32 = 4096;
pub fn options(root: &Path, shard_count: u16) -> StoreOptions {
options_with_index_runs(root, shard_count, DEFAULT_MAX_INDEX_RUNS)
}
@ -1045,7 +1038,7 @@ pub fn drive_root_cas_retry_row(
.map(|shard| namespace_on_shard(shard, CONTENTION_SHARDS, 0x0CA5_0000 + shard as u64))
.collect();
let engine = open_absent_root(&root, CONTENTION_SHARDS, CONTENTION_MAX_INDEX_RUNS);
let engine = open_absent_root(&root, CONTENTION_SHARDS, DEFAULT_MAX_INDEX_RUNS);
for (index, namespace) in namespaces.iter().enumerate() {
let created = submit_plain(&engine, create_transaction(*namespace, 0x40 + index as u8));
assert!(
@ -1160,7 +1153,7 @@ pub fn drive_root_cas_retry_row(
disarm(serial);
drop(engine);
let reopened = reopen_after_close(&root, CONTENTION_SHARDS, CONTENTION_MAX_INDEX_RUNS);
let reopened = reopen_after_close(&root, CONTENTION_SHARDS, DEFAULT_MAX_INDEX_RUNS);
let recovered = reopened
.transaction_status(namespace, victim_operation)
.expect("status read");

View File

@ -2394,7 +2394,7 @@ there.
**`max_index_runs` is now a named required member of `resources.configured_ceilings`.** It was
reachable only through that block's free-form `additionalProperties`, so an emitter could omit
the one ceiling this workload actually reaches — `submit` refuses `NotImplemented` at it — and
the one ceiling this workload actually reaches — the run seals against it — and
the bundle stayed valid. It must be the value the run configured, read back from the options the
store opened with. The schema cannot see the process's options, so the bite is a cross-check:
`index_run_ceiling: "store_default"` bounds the recorded value at 64 and

View File

@ -75,12 +75,15 @@ else
fi
echo "== crash matrix has no pending rows at Phase 1 exit =="
# During Waves A and B the fixture legitimately carries pending-wave-b rows.
# This check only fires once B1 has landed engine.rs, at which point a pending
# row means a forgotten failpoint rather than a sequenced one.
# During Waves A and B the fixture legitimately carried pending-wave-b rows, so
# this check was gated on B1 having landed engine.rs -- proxied by engine.rs no
# longer mentioning `NotImplemented`. That proxy stopped holding: B1 landed, and
# the only mentions left are a module doc and two tests asserting an error is
# *not* one, so the grep matched and the check silently stopped running. B1's
# deliverables are complete, so the transitional guard is gone and a pending row
# is now always a forgotten failpoint.
matrix=crates/levcs-store/tests/fixtures/phase1-failpoints.json
if [ -f "$matrix" ] && grep -q 'fn submit' crates/levcs-store/src/engine.rs \
&& ! grep -q 'NotImplemented' crates/levcs-store/src/engine.rs; then
if [ -f "$matrix" ]; then
if grep -q 'pending-wave-b' "$matrix"; then
echo "engine.rs is implemented but the crash matrix still has pending rows:" >&2
grep -n 'pending-wave-b' "$matrix" >&2