Session log corrupt after interrupted tool call + restart: seq overlap in committed region

[Lowlife555]

Summary

Session history becomes unloadable (history unavailable) after an interrupted tool call followed by a restart: the session log gets two event blocks with overlapping seq values (old "interrupted" placeholder events + replayed real events), and the loader rejects it as a corrupt log.

Environment

• dsh 0.1.0-rc.7, web profile, Windows 11, Node 26
• Triggered on a normal dsh web run (no custom patches)

Error

history unavailable for session "<id>": Error: corrupt session log: seq gap in committed region at line 1532 (expected 34898, got 34893)

Reproduction path

1. During a conversation, a tool call is interrupted (aborted / user interrupt). The session store appends placeholder events:
   • tool/result ×2 with message.id = interrupted-tool-result-... (seq N, N+1)
   • step/end (seq N+2), turn/end with reason: "interrupted" (seq N+3), session/end-seed (seq N+4)
2. Restart dsh web; the session resumes and replays from the last checkpoint. Replay re-runs the interrupted step and appends the real tool/result / tool/call events — with seq re-allocated starting again at N.
3. Result: seq N..N+4 now appears twice in the log (old placeholders + replayed real events). The loader walks the committed region, sees seq go backwards (expected 34898, got 34893), and marks the log corrupt.

Log evidence (decoded from session.jsonl.zstd)

{"type":"tool/result","seq":34893,"time":1786969882390,..."id":"interrupted-tool-result-call_00_..."}  <- old placeholder
{"type":"tool/result","seq":34894,"time":1786969882390,..."id":"interrupted-tool-result-call_01_..."}  <- old placeholder
{"type":"step/end","seq":34895,"time":1786969882390,...}
{"type":"turn/end","seq":34896,"time":1786969882390,"data":{"turn":5,"reason":{"kind":"interrupted"}}}  <- old
{"type":"session/end-seed","seq":34897,"time":1786970340497,...}                                       <- old
{"type":"tool/result","seq":34893,"time":1786970378363,...}                                            <- replayed real result (8 min later)
{"type":"tool/call","seq":34894,...}                                                                    <- replayed
{"type":"tool/result","seq":34895,...}
{"type":"step/end","seq":34896,...}
{"type":"step/start","seq":34897,...}
{"type":"assistant/chunk","seq":34898,...}                                                              <- continues normally

Impact

• The affected session's history cannot be loaded in the UI; the current conversation itself keeps working and keeps appending.
• No data is actually lost (the replayed real events are all present), but the duplicate seq block makes the file invalid.
• Any user hitting "interrupt a running task, then restart / resume the session" can trigger this.

Suggested fix

When resuming/replaying after an interruption, the write watermark should resume from the last seq of the committed region (skipping the interrupted placeholder events), or the replay should first truncate/overwrite the placeholder block so no seq range is written twice.

Manual workaround used: decode the zstd log, drop the 5 placeholder lines whose seq range overlaps the replayed block, re-encode — history loads again.

[argszero]

Great report — complete repro path, log evidence, and a working manual fix. I traced the mechanism through the rc.7 source (99f6f02fec), and your data reveals something more specific than "replay re-allocates seqs". Here's the source-grounded picture, plus why your suggested fix lands in the right place.

1. The normal seed path cannot produce your overlap. On restart, prepareCore (packages/session/session-persistence/src/coordinator.ts:885-920) seeds the session from the full stored event list plus synthetic closers from interruptedTurnClosers (packages/core/session/src/repair.ts:27-131). Seeded seqs must be contiguous from 0 (index.ts:525-527), firstLiveSeq = this.log.length (index.ts:539), and the append base is this.log.length (index.ts:604+). So a session resumed from the full stored log continues at last+1 — no overlap possible. Your placeholders (interrupted-tool-result-..., written live by the agent loop's abort path, tool-calls.ts:244-262) would be in that seed.

2. So the overlap means the resume seed EXCLUDED the placeholder block while the file retained it. The only mechanism that fits: the resumed session was prepared from a stale prepared source — the SessionPreparations cache (preparations.ts:32+) retains a bounded set of prepared sources, and isPreparedSourceCurrent (coordinator.ts:964-968) validates one by comparing readStoredRevision(...) === source.revision. But the write-behind batch controller (writeBatchMaxDelayMs, jsonl index.ts:82/131) batches appends — a freshly-written placeholder batch may not yet have bumped the durable revision when the resume path reuses a cached prepared source that predates it. The cache check then passes against a revision that hasn't advanced, and the resume seeds from the stale (pre-placeholder) log while the file physically retains the placeholders → the replayed real events land on the same seqs. This is the same family as the "resume-path fresh-load" gap (#2167): resume must load the freshest committed state, never a cached source whose revision lags the file.

3. Your manual fix (drop the placeholder block) is the correct recovery, and it maps to a durable invariant. The placeholders are entirely redundant once the replay has produced real events — they were only needed to keep the crash tail balanced until the turn could be replayed. The loader's session/end-seed marker (index.ts:545-547) is the committed-region boundary; if the resume path treated "seed to end-seed, replay open turn from there" as the invariant, the placeholder block would be the natural truncation point instead of a poison.

4. Concrete fix directions (any subset):

• Fresh-load on resume with an open turn: if interruptedTurnClosers(storedEvents).length > 0 (an open/interrupted turn exists at load), bypass the prepared-source cache and load the raw stored log (coordinator.ts:960-968 path) so the seed always includes the just-committed placeholders. This closes the stale-cache window entirely.
• Revision-bump on write-behind commit: ensure appendBatch's durable commit bumps the revision before any prepare can read it (currently the revision is read from the backend, but a cached prepared source's revision is captured at prepare time — the seam is the write-behind delay).
• Recovery: your truncate-the-placeholder-block manual fix is a good candidate for dsh-doctor (moonquake2004's dsh-doctor: an offline diagnostic for the failure classes this community keeps reporting #1534) as an offline check: detect tool/result with id prefix interrupted-tool-result- followed by a replayed block overlapping its seqs → drop the placeholder lines. Deterministic and safe (the real events are present, as you showed).

5. Impact note: this is the 8th corruption-family report (mechanisms across #1333/#1452/#1497/#1473/#1586/#2167/#2342), and the first one on rc.7. It's a resume-path coherence bug rather than a crash-durability bug — which is why it survives the recent durability hardening (zoahdev's #2342 fixes targeted the cold-load liveness and synthetic-tail paths, not the prepared-source staleness window). Worth elevating: "interrupt then restart" is a very common user action.

Thanks for the decoded log evidence — it made the mechanism unambiguous.