[bug] Duplicate seq written to session log when seed-construction and resume overlap (bionic: no write lease → whole history rejected on read)

[240xu]

Environment

• Termux / Android arm64 (bionic), Node v26, dsh 0.2.0-rc.2
• Session format: v4 (session.v4.jsonl.zstd, multi-frame zstd)

Observed error (UI, when opening history)

stored session is corrupt: corrupt session log: invalid committed event at line 2664:
released v2 row 2663 has seq gap (expected 2663, got 2662)
(raw log: <home>/.dsh/sessions/<encoded-cwd>/session-<id>/session.v4.jsonl.zstd)

File evidence (decoded frames, times anonymized)

frame	seq	type	note
1479	2661	turn/end	last row before the race
1480	2662	session/end-seed {}	writer A (seed-construction path, dsh-session:1352) — +2.8 min
1481	2662	model/selection	writer B — duplicate, +6.5 min after A
1482+	2663, 2664…	agent/inbox/spliced, turn/start…	B continues contiguously

So rows from the duplicate onward are uniformly seq = eventIndex - 1.

Mechanism

1. Session.seq is defined as this.log.length (dsh-session/lib/index.js, "seq = log.length contiguity contract") — appends never re-check the file tail, so a handle whose in-memory log is one event behind silently writes a duplicate seq.
2. Here two Session objects existed for the same id: A appended session/end-seed from the seed/fork construction path; B had restored earlier (before A's append) and idled 6.5 min, then wrote model/selection with the stale next-seq.
3. On Termux/bionic @deepseek-ai/node-addon-system has no binding, so tryLockExclusive throws ERR_FLOCK_UNSUPPORTED_PLATFORM and the write lease falls back to a no-op (posix-unlocked). On platforms with flock the second opener would fail fast with SessionAlreadyOwnedError; on bionic the race corrupts silently, and the strict monotonic validator then rejects the whole log on read ("历史加载失败" — entire history unreadable).

Suggested fixes

1. Lock fallback that works on bionic: replace the unlocked fallback with an O_EXCL lock-file lease (open(path, 'wx') with pid + mtime heartbeat). Exclusive create works on Android/Termux filesystems and would restore cross-process exclusion instead of a no-op lease.
2. Flush-time tail verification: before publishing an append batch, re-read the tail seq (or track a shared file offset); if it moved, throw SessionAlreadyOwnedError instead of writing a duplicate.
3. Reader-side containment: a single duplicate seq currently rejects the entire session. Since the offset is uniform (+1 from the duplicate onward), the reader could renumber-and-warn (or quarantine with a copy) instead of making all history unreadable.

Repro pattern

Any fork/seed construction overlapping a plain resume of the same session id on a host without flock (Termux). Not reproducible on Linux/macOS because the lease rejects the second writer first.

[LanceRingHong]

Independent Windows report: same duplicate-seq failure on Desktop 0.2.1-rc.5 (Windows 11 x64), so this is not limited to bionic.

Environment

• DeepSeek Harness Desktop 0.2.1-rc.5, Windows 11 x64, bundled Node 24.21
• Session format v4 (session.v4.jsonl.zstd, multi-frame zstd)
• A second dsh web host (web profile) was also running against the same <DSH_HOME> at the time; it was stopped afterward. Cross-process exclusion did not prevent the duplicate on Windows either.

Observed

• Loader error: invalid committed event at line 1457: released v2 row 1456 has seq gap (expected 1456, got 1455).
• Decoded rows:
  • seq 1454 turn/end (aborted turn)
  • seq 1455 session/end-seed {} at 02:32:21
  • seq 1455 agent/inbox/spliced at 02:33:29
  • seq 1456 turn/start
  • 3093 later events uniformly seq = eventIndex - 1
• The end-seed row has no conversation content; the user message also exists as a normal user/message, so nothing was lost.

Analysis

• append() uses seq = this.log.length; a duplicate requires two Session objects for the same id, one holding a seed/log snapshot from before the marker — matching the seed-construction/resume overlap described here.
• On this Windows host the second writer was not rejected. Either the write lease is a no-op / not truly cross-process on Windows, or both Session instances were in one process and the lease is per-process only. Worth checking the @deepseek-ai/node-addon-system Windows binding and the lease path.

Repair / workaround

• Removed the duplicate session/end-seed row (kept the paired inbox splice), recompressed header frame + ~256 KiB event frames; the official verifier passed.
• Result: 4548 events, 88 user messages, 566 assistant messages, zero content loss.
• Operational mitigation: only one DSH host per <DSH_HOME>; do not run desktop + dsh web/CLI concurrently; back up sessions before restarts.

Suggested fixes

• Cross-process lease on Windows (LockFileEx or O_EXCL lease file with heartbeat) plus a per-session owner guard within a process.
• Before publishing an append batch, re-read the tail seq / shared offset; if it moved, throw SessionAlreadyOwnedError.
• Reader-side containment/quarantine instead of rejecting the entire history.

Happy to provide sanitized row snippets or the repair/verify scripts.

[240xu]

我做了一个sessionfix插件你可以看一下