[Bug] Concurrent writing to the same session log corrupts seq (corrupt session log: seq gap in committed region)

[cyhano]

[Bug] Concurrent writing to the same session log corrupts seq (error: corrupt session log: seq gap in committed region)

Summary

When two DSH instances write to the same session at the same time (e.g. the web instance on :3080 and a desktop/client instance), the session log's seq counter races and can go backwards, producing:

Error: corrupt session log: seq gap in committed region at line 8 (expected 7, got 4)

Newer builds validate the committed region strictly and refuse to load the whole session history once this happens, so the affected conversation becomes unreadable.

Environment

• DSH: 0.1.0-rc.7 (/opt/homebrew/bin/dsh, managed by PM2)
• Node: v26.3.0
• OS: macOS 26.5.2 (arm64 / Apple Silicon)

Root cause (observed evidence)

The corrupt session session.jsonl.zstd contains a seq that jumps backwards (not the normal forward gaps caused by assistant/chunk streaming):

line 8:  seq=6  agent/inbox/spliced   time=1787141515142   (old segment)
line 9:  seq=4  agent/inbox/spliced   time=1787143675752   (new segment, ~36 min later)
line 10: seq=5  turn/start
line 11: seq=6  agent/inbox/spliced
line 12: seq=7  agent/inbox/spliced
line 13: seq=8  step/start
...

Line 9 should continue from seq=6 (i.e. 7, 8, 9, …) but was written starting again from seq=4. The timestamp gap (~36 minutes) and the duplicated 4,5,6 sequence indicate two instances were appending to the same file concurrently, each unaware of the other's counter.

I repaired it locally by re-numbering every seq from line 9 onward by +3, which restores strict monotonic increase and recovers the history without dropping any content. But this is a data-corruption bug — the writer should make per-session seq allocation atomic / single-writer.

Related issue

A separate symptom of the same concurrency situation: when the process is restarted under PM2 while the previous dsh process hasn't released port 3080 yet, the new instance crashes with listen EADDRINUSE: address already in use 127.0.0.1:3080, and PM2 enters a crash-restart loop (observed 431 restarts). It eventually self-resolves once a process wins the port, but the port-bind error / restart loop may deserve a look too.

Suggestion

1. Make per-session seq allocation single-writer (e.g. a session-level append lock, or derive seq from a shared counter) so concurrent instances can't race.
2. Consider softening the strict committed region validation to tolerate (and maybe auto-repair) a small backwards gap instead of making the whole history unreadable, or at least surface a clearer recovery path.

Thanks for the great tool!

[denial123789]

The rc.7 JSONL scanner supports one narrow crash case: finish() ignores a final record without a newline as a torn tail. It does not treat a sequence mismatch inside the committed region as a recoverable tail. In consumeEventLine, every decoded event must equal the current event count; the scanner remembers the first mismatch, and a later turn/end makes it fatal.

That makes the backwards 6 → 4 jump valuable evidence of a writer-ownership violation. I would stop every process sharing the session root before attempting any repair, preserve the complete original directory byte-for-byte, and verify process/root ownership before restarting. Renumbering can make this one invariant pass while silently invalidating packed-row boundaries or references, so it is safer as a forensic experiment on a copy than as the default recovery path.

Useful regression gates for a fix: two processes cannot append to one session; the loser fails before writing; torn-tail recovery remains limited to the uncommitted tail; committed sequences stay contiguous after restart; errors identify the session without exposing message content.

I mapped this signature separately from Zstandard framing and client-side tool-ID collisions here: https://sandbaseai.github.io/deepseek-harness-handbook/session-history-recovery.html

Disclosure: independent SandBase community handbook, not official DeepSeek documentation.