From 660b4c74d08c4fdf662d9f9c5d55ffb221a2a187 Mon Sep 17 00:00:00 2001 From: Levi Neuwirth Date: Sun, 9 Aug 2026 18:13:14 +0200 Subject: [PATCH] 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 Claude-Session: https://claude.ai/code/session_01JGdH5V43XWnj1PdHqiPktQ --- crates/levcs-store/src/bin/store-bench.rs | 4 ++- .../tests/support/engine_matrix.rs | 35 ++++++++----------- doc/instance-throughput-rewrite-plan.md | 2 +- scripts/check-phase1.sh | 13 ++++--- 4 files changed, 26 insertions(+), 28 deletions(-) diff --git a/crates/levcs-store/src/bin/store-bench.rs b/crates/levcs-store/src/bin/store-bench.rs index 325916f..c3683f8 100644 --- a/crates/levcs-store/src/bin/store-bench.rs +++ b/crates/levcs-store/src/bin/store-bench.rs @@ -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)), diff --git a/crates/levcs-store/tests/support/engine_matrix.rs b/crates/levcs-store/tests/support/engine_matrix.rs index 3ca3d85..7637732 100644 --- a/crates/levcs-store/tests/support/engine_matrix.rs +++ b/crates/levcs-store/tests/support/engine_matrix.rs @@ -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"); diff --git a/doc/instance-throughput-rewrite-plan.md b/doc/instance-throughput-rewrite-plan.md index 62ddc75..ffb9a74 100644 --- a/doc/instance-throughput-rewrite-plan.md +++ b/doc/instance-throughput-rewrite-plan.md @@ -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 diff --git a/scripts/check-phase1.sh b/scripts/check-phase1.sh index df010e8..1528c5f 100755 --- a/scripts/check-phase1.sh +++ b/scripts/check-phase1.sh @@ -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