v0.1.7: the whole-file lane's chain charge counts its group, and history-stride10 no longer completes (#190)

[yifanxuaaa]

Status: defect on main at eb2c06e2; diagnosis, mechanism and fix measured. Filed 2026-09-22 from the run that found it. history-stride10 is a registered admission row outside the 217 (#190's lane), so this blocks that lane's evidence on this tree.

1. What fails

history-stride10 no longer completes:

$ LAYERFS_CONSTRUCTION_WORKERS=1 LAYERFS_HISTORY_ADVISORY=1 LAYERFS_HISTORY_DEPTH_LIMIT=7 \
    fs-bench-storage-content --case history-stride10 --corpus <corpus> --out /tmp/x
history-stride10 INCOMPLETE gates=1

g1.o1-chain-complete  INCOMPLETE  product error: Integrity("dependency encoded work")

Deterministic: three fresh runs, ~3.5–5.3 s wall, abort at 17.1 MB of Store (4,041 pages, apparent_bytes 16,551,936 in all three). Also reproduced through runner.py perf (benchmark-results/history-stride10/stride10-20260922T121313Z, repeat-20260922T121442Z, stride10-l7-20260922T121536Z).

It is not the budget, not the corpus (history_corpus.self_check clean: 17 states / 101,477 path states / 561,010,345 B), and not the history switches: LAYERFS_HISTORY_ADVISORY=1 LAYERFS_HISTORY_DEPTH_LIMIT=7 and LAYERFS_HISTORY_CHUNK_PREDECESSORS=0 all abort. The harness's own documented refusal (advisory depth u8::MAX, "the product currently rejects") is a different one.

2. It passes on every archived build

Same corpus, same declared switches:

build	result	operation	Store
stage-6-history-190-opt-20260919T232858Z/binaries/baseline-c5826d20… (Sep 19)	PASS 17/17	46.70 s	49.4 MB
stage-6-history-209-merged-20260920T225623Z/binary-archive/merged-main (Sep 20)	PASS 17/17	23.54 s	52.2 MB
main @ eb2c06e2 (today)	INCOMPLETE	—	aborts at 17.1 MB

3. Mechanism

record_width charges a chain read the group's width for the whole-file lane (core/crates/layerfs-storage/src/encoding/delta/read.rs:527), while the budget it is charged against is per chain — CHAIN_ENCODED_LIMIT = 256 KiB (policy.rs:183). That early return was written when the lane sealed one record per group, so group width ≡ record width. a1faf957e ("group the compact whole-file lane") gave the lane whole groups — its own census puts it at 519 groups instead of 9,444 — so every chain read is now charged the group's membership, and a depth-8 chain asks for roughly eight group targets (~384 KiB) against 256 KiB.

Verified by construction: restoring the pre-a1faf957e seal rule (PackLane::WholeFile => occupied) in a temporary diagnostic build makes the same case pass — 15.63 s, 17/17 states, 71.1 MB. The edit was reverted immediately; the tree is clean and the binary hashes back to 90a04b44….

Secondary: on the abort path phases-perf.json reports preparation + verification larger than the invocation wall (8.75 s inside 5.34 s), so g7.phase-reconciliation fires. The gate is right; the document is wrong when the driver aborts.

4. Fix (owner-authorized option A), implemented and measured

record_width no longer special-cases the lane: it takes the Raw arm every other lane takes and charges the record its locator names. The lane seals GroupCodec::Raw by construction (pack/assemble.rs:185), so that arm is exact for it.

• Production LOC 97,249 → 97,246 (delta −3); the added lines are the explaining comment.
• history-stride10: PASS 17/17, operation 15.06 s, and all 17 state roots identical to the Sep-19, Sep-20 and diagnostic runs.
• history-stride3: PASS 53/53, 37.10 s, 106.7 MB.
• pipeline-namespace-100000: 15/15 gates, 14/14 pinned counters, digest 2412681d… unchanged (statements 12,206 / commits 388 / inserted 113,635 / content_bytes 502,914,928), i.e. no other row's pin moves.
• 110 test binaries, 631 passed / 0 failed; clippy clean; fmt clean; core/tools/check_product_boundary.py PASS.

The cost, stated plainly. Nine objects change representation — delta.prefix_selected 38,117 → 38,108 and delta.full_records 12,998 → 13,007 — because the reader's charge feeds the selection's own chain budget. The row is therefore not byte-identical to the pre-grouping arm; its 17 roots are.

Option B (charge only what was fetched) is not taken. A alone cleared the lane, and B changes more semantics ("encoded bytes this wave read") for no measured need. It stays in the priced list rather than in the diff.

5. Why the crate tests did not catch it

chain_encoded_limit is a constant with no test-visible override, the whole-file chain depth caps at 8, and the closest expressible in-crate shape charges 240,607 of 262,144 — 8 % short of the refusal. So the lane is the only oracle that reaches this boundary, and that is recorded rather than papered over. A future round that wants a unit test here needs a test-visible capacity override first.

6. Not in this issue

• The store-size axis of grouping on this lane (63.3 MB with the fix, 71.1 MB with one-record groups on the same tree, 52.2 MB on the Sep-20 build) is measured but not attributed: the three differ in more than the seal rule.
• history-stride1 was not run (157 states, the campaign's own budget ruling keeps it out of these rounds).
• Raising CHAIN_ENCODED_LIMIT is not proposed: it is a bounded-work guarantee with its own test (tests/delta_chains.rs:83).

Evidence: docs/roadmap/0.1/0.1.7/evidence/issue228-stride10-chain-charge-20260922T124500Z/report.md (runs under benchmark-results/history-stride10/ and benchmark-results/postfix/).

[yifanxuaaa]

Filed, implemented and measured — the working tree carries the fix; nothing is committed yet.

• Evidence: docs/roadmap/0.1/0.1.7/evidence/issue228-stride10-chain-charge-20260922T124500Z/report.md, with raw/ holding the post-fix history-stride10 and history-stride3 traces, the pre-grouping seal-rule diagnostic, two of the three failing windows, state-roots.tsv (the 17 roots across four builds) and postfix-pipeline-pins.txt.
• Ledger: L96 in docs/roadmap/0.1/0.1.6/evidence/issue151-experiment-ledger.md.
• Fix: core/crates/layerfs-storage/src/encoding/delta/read.rs — record_width no longer special-cases the whole-file lane. Production LOC 97,249 → 97,246 (delta −3).
• Verified on the fixed tree: history-stride10 PASS 17/17 (15.06 s), history-stride3 PASS 53/53 (37.10 s), all 17 roots identical to every known-good build, pipeline-namespace-100000 14/14 pins with the digest unchanged, core workspace 631 passed / 0 failed across 110 binaries, clippy/fmt/boundary clean. Harness binary after the fix: fa2eb97f….
• Cost, unchanged from the body: nine objects flip PREFIX → FULL (prefix_selected 38,117 → 38,108, full_records 12,998 → 13,007), so the row is not byte-identical to the pre-grouping arm. Option B remains priced and untaken.

Two things a reader should not assume: the three post-fix runs are single diagnostics on a host whose anchor read +29.6 % to +45.9 % — no timing claim is made — and the store-size axis of grouping on this lane is measured but not attributed.

[yifanxuaaa]

history-stride1 run on both trees — the defect reached all three lanes, and the fix clears all three.

build	result	wall	Store
unfixed (90a04b44…)	INCOMPLETE, same Integrity("dependency encoded work")	3.62 s	aborts at 6,742,016 B
fixed (fa2eb97f…)	PASS 157/157 states	166.28 s (operation 112,818,249,543 ns)	212,779,008 B

Declared arm in both cases (LAYERFS_HISTORY_ADVISORY=1 LAYERFS_HISTORY_DEPTH_LIMIT=7), same corpus. stride1 is the cheapest reproduction of this defect — 3.6 s instead of stride10's 3.5 s abort after a longer setup — which is worth knowing for anyone who touches the whole-file lane again.

The fixed run's delta.inserted 97,788 and prepared_full 78,619 match the #190 attribution round's own stride1 figures exactly, so this lane is running the work it always ran. The figure the charge change moves is trials (70,710 recorded, 70,562 here). Peak RSS 431,669,248 B is published, not claimed; no timing claim is made — one diagnostic per tree, uncontrolled cache residency, host anchor at +29.6 % to +45.9 % today.

Evidence updated in place: raw/stride1-fixed.*, raw/stride1-unfixed.*, and section 5b of the report; ledger L96 carries the same addendum.

[yifanxuaaa]

The stride1 run is state-for-state equal to every archived stride1 run — 157 of 157 roots, eight builds.

The evidence tree already holds eight archived 157-state stride1 traces (#190 baseline / candidate / instrumented, the #205 save-split instruments, and the Sep-20 merged-main build). The fix's stride1 run was compared against all eight, root by root:

IDENTICAL: all 157 roots   stage-6-history-190-corpus-phase-…/diagnostic-history-stride1
IDENTICAL: all 157 roots   stage-6-history-190-save-…/baseline-history-stride1
IDENTICAL: all 157 roots   stage-6-history-190-save-…/candidate-history-stride1
IDENTICAL: all 157 roots   stage-6-history-205-save-split-…/instrument-history-stride1
IDENTICAL: all 157 roots   stage-6-history-205-save-split-…/instrument2-history-stride1
IDENTICAL: all 157 roots   stage-6-history-205-save-split-…/mix-history-stride1
IDENTICAL: all 157 roots   stage-6-history-205-save-split-…/probe-history-stride1
IDENTICAL: all 157 roots   stage-6-history-209-merged-…/merged-history-stride1

8 of 8 archived runs reproduce all 157 roots exactly

That is a stronger correctness statement than the stride10 evidence carried (four builds on 17 roots): at the finest lane the fixed tree reproduces the pre-regression lane's canonical output exactly, state for state.

What is not compared, and why: the store constant the #190 round recorded (1635cf7bb…) — the driver does not publish it and the historical Store is not archived — and delta.trials, which the charge change legitimately moves (70,710 recorded, 70,562 here).

Filed as raw/stride1-roots-crosscheck.txt; report section 5b and ledger L96 updated in place.

[yifanxuaaa]

A separate finding surfaced while validating this fix — filed as #229.

The stride1 Store's content matched the archived build exactly (157/157 roots, inserted 97,788, trials 70,562), but its size did not: 88,944,640 B on the Sep-20 archived build against 212,779,008 B here, same corpus and same arm. The cause is pack reservation, not content — object_packs holds 855 rows averaging 85,432 B (min 180) there and 784 rows that are all exactly 262,144 B here, because a created row is inserted as zeroblob(capacity) and appended in place (sqlite/write.rs:95; pack/placement.rs:52-54: "Every lane but Singleton allocates its full pack limit").

Two things that matter for this issue:

• It is not this fix. The charge change moves 11 records on stride1 (prefix_records 78,548 → 78,537, full_records 19,240 → 19,251), and a diagnostic build with payload_is_incompressible forced off produced an identical Store (212,815,872 B).
• It buys real time, which is why it is a ruling question and not a bug: on those same two runs delta.statements 75,990 → 2,602 and delta.pack_appends 84,492 → 11,168.

§5c of the report and raw/pack-allocation.tsv carry the measurement; #229 carries the four priced remedies.