Session log becomes unreadable after interrupted retry duplicates committed seq values

[worker100]

Summary

I reproduced a session-history loading failure on Windows with DeepSeek Harness 0.1.0-rc.8.

The UI reported:

corrupt session log: seq gap in committed region
(expected 267594, got 267590)

Observed log pattern

The durable event stream contained a committed sequence through 267593, then a retry appended the same sequence range again:

267590, 267591, 267592, 267593
267590, 267591, 267592, 267593
267594, ...

Removing the second copy restored a contiguous sequence through the end of the session. No session identifiers, local paths, credentials, or raw logs are included here.

Trigger

The duplicate range appeared after a tool call was interrupted during a restart/test flow. The interruption recorded an outcome, and a later retry/recovery path persisted terminal events for the same attempt again.

Expected behavior

A retry or recovery path should not append an event batch whose first sequence is older than the current durable cursor. The append should either be rejected as stale/idempotently ignored, or the session should remain recoverable with a clear repair marker.

Suggested fixes

• Enforce a per-session single-writer/serialized append boundary across cancellation and retry paths.
• Compare the incoming batch's first sequence with the durable cursor inside the same atomic transaction/lock as the append.
• Make retries idempotent using an attempt or batch identity, not only sequence numbers.
• Add a regression test for interrupt → terminal-event persistence → retry/recovery.
• Keep the existing corruption diagnostic, but provide a safe duplicate-suffix recovery path when the duplicate range is unambiguous.

I recovered the affected local session by preserving the original file and removing only the verified duplicate event range. I am reporting this without attaching the session data because it may contain private conversation content.

[denial123789]

I traced the relevant rc.8 persistence boundaries. The shared coordinator normally serializes appends per Session ID and rejects any batch whose event sequence does not continue its in-memory cursor. The write-behind controller retains failed batches for retry.

That means a stale retry through the same healthy coordinator should fail rather than append the duplicate. The observed durable range therefore needs one of these branches proved: multiple processes/coordinators reached the same artifact; a writer bypassed the shared coordinator; a restart landed after backend durability but before live cursor acknowledgement; an older artifact/cursor was restored; or decoding reconstructed packed rows incorrectly. rc.8's own persistence contract explicitly notes that revision freshness checks do not add cross-process writer exclusion.

The scanner is right to refuse this as committed corruption. A complete later turn/end means it is not the supported newline-less torn-tail case.

For recovery, I would stop every writer, copy and hash the whole Session directory, expand packed/compressed records with the exact-version decoder, and compare the complete logical event values—not only seq. A repair is safe to automate only when there is one unique identical earlier block, the stream resumes at the original expected sequence, every event/reference matches, and the full Session invariants pass after hypothetical removal. The tool should stage a new artifact and cold-load/replay it in an isolated home; never renumber or edit the sole live file.

For prevention, durable revision/next-seq comparison, append, sync, and acknowledgement need one cross-process critical section plus a stable batch identity. A retry of an already committed identical batch can then be idempotent success; same identity with different content or a new identity behind the durable cursor must fail.

Full source-backed runbook and regression matrix:
https://sandbaseai.github.io/deepseek-harness-handbook/duplicate-session-seq.html