A spanning import can strand a segment in the active tier that no key filter covers; its in-window keys read as absent

[PaulSnow]

Found by review, not by failure. Latent today, and masked by a second defect.

The stranding

handoffBelowWindow (segstore.go:1137) stops at the first segment whose oldest block is inside the window:

for _, seg := range s.active {
    if seg.meta.first() >= start { break }  // "Ordered: the rest are inside the window too"
    n++
}

That assumes s.active is ordered by first(). Seals satisfy it: a seal has Span == 0, so first() == Height. An import does not. ImportSegmentFile appends a segment whose Height is the highest in the store (it must be) but whose Span > 0 puts its first() below segments already in active.

Concretely, with N=20: active holds P{Height:125, Span:0, first:125}. Import Q{Height:130, Span:28, first:102}; at tierStart=100 it joins active correctly. The block reaches 140, wanted=[120,140], the filter at 100 that held Q's keys is dropped, the new filter at 120 is built only from segments with first() >= 120 so Q is excluded, and the handoff loop breaks on P.first()=125 >= 120 before ever reaching Q.

Q is now in active, below the window, covered by no filter. findActive (segstore.go:1901) returns immediately when the filters say no, without walking active at all, so Q's keys read as absent — and they are keys at blocks 120..130, inside the window, so this is a false absent by the filters' own claim rather than a windowing decision. Put of one of those keys with a different value is then accepted, which is the immutability breach the check exists to prevent.

It self-heals on reopen, because load re-tiers by first().

Why it is latent

SegmentInfo (segment.go:45) has no Span field, so a block export drops it and every imported segment arrives claiming one block. That keeps active ordered — and is itself wrong, because spec 1.4 gives Span exactly so a filter cannot claim a merged segment whose older keys it never saw. The two defects mask each other, and closing either one alone exposes the other.

The same assumption again

SetFilterBlocks (keyfilter.go:330) scans s.history backwards for first() >= start and stops at the first that fails. s.history is ordered by (Height, Seq), not by first(), so a qualifying segment before that point stays in history, uncovered by the rebuilt filters. Its own doc comment says this is the thing it is protecting against.

Notes

No test imports a spanning segment; keyfilter_test.go:550 and segstore_test.go:268 import Span == 0 seals only. A fix wants a test that imports Span > 0 and then rolls the window past it.

[PaulSnow]

Context, and the other half

Found during a review of key management for history, run alongside an Accumulate soak. Accumulate is a separate repository on GitLab: https://gitlab.com/accumulatenetwork/accumulate

Companion issues there, both filed from the same session:

• https://gitlab.com/accumulatenetwork/accumulate/-/work_items/4278 — Message(H).Main is classified write-once but its stored value depends on the writing bundle, so one key is written with two values. The store refuses it 10,078 times per node, which is how it was found.
• https://gitlab.com/accumulatenetwork/accumulate/-/work_items/4279 — a Directory store view held open six hours on every node, with a 36 MB evidence capture at test/docker/soak/runs/20260915T042428Z/capture-heldview-140038Z/ in that repo.

Soak run behind both: 20260915T042428Z, BlockchainDB main fac421a (PRs #85 and #89 merged), 500 tps, chaos off, 8 validators. The store held up in it: block production 0.505 s against a 1 s interval, read probes 2–3 ms, and the history walk gone per the new StoreStats gauges. The ceiling was the executor, not the store.