[BUG] 会话日志损坏：关机中断后 seq 序号冲突——"中断收尾"事件与真实事件的 seq 撞号，导致会话无法加载

[LengMu-Cloud]

环境

• dsh: 0.1.0-rc.6（npm 全局安装），Windows，Node v24.19.0
• 后端：dsh-session-persistence-jsonl，zstd 压缩

现象
关机重启（进程被强杀）后，有两个会话无法加载，报错如下：

history unavailable for session "session-36879fd7-...": Error: corrupt session log: seq gap in committed region at line 28404 (expected 501265, got 501263)（internal）
history unavailable for session "session-bc87e08a-...": Error: corrupt session log: seq gap in committed region at line 4120 (expected 69108, got 69105)（internal）

从日志字节中定位到的根因
两个日志里都出现了同一批 seq 序号被使用两次的情况：一次是"回合中断"的合成收尾事件（step/end + turn/end {reason: interrupted}，时间戳复用了上一条事件的），另一次是真实事件（assistant/chunk / tool/result + step/end + step/start，时间戳更晚）。且文件之后继续连贯——说明真实写入方当时还活着、还在继续追加，而加载侧的修复逻辑同时注入了收尾事件：

seq 501262 step/start  （turn 27 step 27）
seq 501263 step/end    <- 合成收尾（复用 501262 的时间戳）
seq 501264 turn/end    <- 合成收尾 "interrupted"
seq 501263 assistant/chunk  <- 真实事件（晚 3.9 秒）
seq 501264 assistant/chunk  <- 真实事件
seq 501265+ ... 继续真实 turn 27 的内容

SessionLogScanner.consumeEventLine 里对 seq 连续性做了严格校验（event.seq !== this.events.length），撞号后直接拒绝加载整个会话。两个文件末尾都是以 turn/end (completed) 正常结束的，所以这个冲突是运行中途由"加载时修复"与"正在写入的进程"竞态造成的，而不是最后一次关机瞬间写坏的。

期望行为
撕裂尾部的恢复逻辑（commitRepair 重放恢复的事件 + 追加合成收尾）不应与并发写入方产生 seq 撞号；理想情况下，如果后续真实事件证明该回合其实并未中断，加载器应当能通过丢弃合成收尾事件来恢复会话。

相关讨论：#483（强杀进程后 write-behind 批处理丢失未刷新的尾部数据）、#1593（会话日志损坏导致会话永久不可用）。

补充说明：我的两个会话已通过本地脚本修复（扫描定位 seq 撞号 → 删除合成收尾行 → 按原格式重新编码），验证可正常加载，此贴不是求助帖，是报告底层缺陷。附修复思路供参考：这类"合成收尾事件与真实事件撞号"的损坏，可通过比对事件类型和时间戳（合成收尾时间戳复用上一条事件、且为 step/end + turn/end interrupted）识别并删除合成行恢复；但手动编辑日志有风险，且不覆盖"缺号"等其他损坏形态，建议官方实现自愈逻辑（丢弃合成收尾、或修复时与写入方串行化）。

[argszero]

你的根因定位是对的，而且这是会话损坏家族的第 7 个机制——一个我追踪已久但一直没等到现场证据的缺口：冷加载修复路径缺少 liveness 检查。我验证了完整链路。

1. 机制确认（master 47f9438）

• 合成收尾由 interruptedTurnClosers 生成（core/session/src/repair.ts:27）：对"不平衡"的日志（有 open turn/step 无 turn/end）生成 step/end + turn/end {reason: interrupted}，seq 从 last.seq + 1 续（:85），时间戳复用最后一条真实事件——与你日志里的字节完全吻合。
• 冷加载路径 coordinator.ts:903：prepareCore 从持久化存储读取后无条件计算 interruptedTurnClosers(storedEvents) 并 commitRepair 落盘（session-persistence-jsonl/src/index.ts:436-446 appendLines）。没有任何 liveness 检查——它假定"日志不平衡 = 进程崩溃"。
• 但"日志不平衡"也是活写者正在回合中的正常中间态！如果加载发生在活写者还在追加时（第二个进程冷加载、或会话历史查询走了冷路径），修复逻辑就把一个正常的进行中回合误判为崩溃尾巴 → 注入虚假收尾事件（seqs last.seq+1）→ 活写者的内存 seq 计数器不知道这些注入，继续从自己的计数追加 → 撞号 → 永久损坏。
• 关键对照：活会话路径有守卫——loadLiveSnapshot（coordinator.ts:981-984）明确检查 interruptedTurnClosers(events).length > 0 时抛错"cannot load session while its live turn is open"。守卫存在，但只覆盖了活路径，冷路径没有。

2. 家族连接

这是第 7 个机制：#1333/#1452（跨进程 seq 重复）→ #1497（撕裂尾）→ #1473（追加/读竞态）→ #1586（恢复写者 vs 残留写者）→ #2167（过期视图重复追加）→ #2342（加载侧修复注入 vs 活写者）。共同主线不变：append/repair 路径没有"谁拥有这个日志"的持久契约。#2342 是 #1586 的镜像——#1586 是恢复进程 vs 残留写者，本帖是加载侧修复 vs 活写者；也是 #2167 的兄弟（seq 计数器从过期的已提交前缀派生）。

3. 修复方向（按价值排序）

1. 冷路径 liveness 检查（根修复）：prepareCore 合成 closers 前先确认没有活写者持有该会话（进程内 session registry 查询 + 跨进程 lease 检查，如 wellorbetter 的 writer-lease [Bug] Cold history loading fully materializes large/corrupt logs and can stall the entire Web server #1550）。有活写者 → 跳过修复，让活会话作权威。这直接把 [BUG] 会话日志损坏：关机中断后 seq 序号冲突——"中断收尾"事件与真实事件的 seq 撞号，导致会话无法加载 #2342 掐死。
2. 持久 seq 断言（与 Bug: session log corrupted on resume - last 4 committed events re-appended with fresh timestamps (seq gap in committed region) #2167 同一建议）：appendLines/commitRepair 落盘前断言 batch 首 seq == committed 长度，不符则响亮拒绝——让"注入 vs 活写者"的第一次冲突在写入时变成大声错误，而不是事后损坏。静默截断不可取（会丢未刷事件）。
3. 读取侧自愈（可选）：你的手工修复思路（识别"时间戳复用 + step/end + turn/end interrupted"的合成行并丢弃）可以作为 scanner 的自我修复逻辑——当撞号后的真实事件证明回合并未中断时，丢弃合成收尾恢复可读性。这与 Bug: session log corrupted on resume - last 4 committed events re-appended with fresh timestamps (seq gap in committed region) #2167 的 reader-self-heal 建议一致。

4. 你的报告质量很高——字节级证据（时间戳复用 + 撞号 + 文件后续连贯）+ 手工修复 + 明确定位，直接把这个"冷路径无 liveness 检查"从我的待验证清单变成了家族第 7 个实证。建议合并进统一的"replay/append 所有权契约"加固工作流（#1333/#1452/#1497/#1473/#1586/#2167 + 本帖）。

[zoahdev]

根因确认：这是「合成尾部事件」（step/end + turn/end {reason: interrupted}）在断电瞬间和随后追加的真实事件撞了 seq——SessionLogScanner.consumeEventLine 的严格 event.seq !== this.events.length 校验直接拒绝，会话就不可恢复。本质是上游的「中断时补写尾部」与「正常追加」没有做 seq 协调，属于 bug。

止血/抢救两条：

npx dsh-shelf verify                      # 标出 orphan tool call / 没 turn/end 的坏会话
npx dsh-shelf rescue <session-id>         # 无视 resume 校验，解码(含 zstd)导出对话内容到 markdown

rescue 不碰 seq 校验，直接捞 user/assistant 内容，能把坏会话里的对话救回来（repo: github.com/zoahdev/dsh-shelf）。

另外这个家族的检测我已经做进 dsh-plugin-doctor v1.16.0（tool-call-pairing 检查），以及 dsh-shelf 的 verify 早就覆盖 orphan tool call——上游修根因之前，这两个是社区里现成的「检测 + 抢救」组合。

[zoahdev]

This is the missing half — my comment stopped at "synthetic tail collides with a real event"; you've traced it to the actual defect: the repair path (prepareCore → interruptedTurnClosers → commitRepair) has no liveness check, so it assumes "log is balanced = process is live" and can splice a synthetic closer onto a session a live writer is still appending to.

The family framing is the key insight: #1333/#1452 (dup seq), #1497 (torn tail), #1473 (corruption), #1586 (restore-writer vs live-writer), #2167 (duplicate append), #2342 (repair-writer vs live-writer) — all the same contract: append/repair has no "who owns the log" check.

Agree with the fix order:

1. repair-path liveness/lease check (kill this class at the source),
2. persistent seq-ownership check at appendLines/commitRepair (reject on mismatch, not corrupt later),
3. reader self-heal as a fallback (mirrors Bug: session log corrupted on resume - last 4 committed events re-appended with fresh timestamps (seq gap in committed region) #2167).

I'll fold your root-cause + fix order into the dsh-docs patch queue (this is a 3-patch family: repair-liveness, seq-ownership, reader-self-heal). If you have a branch already, point me at it and I'll base off it instead of re-deriving.

[zoahdev]

Landed fix #1 (repair-path liveness) as a cherry-pick-ready branch:

zoahdev/deepseek-harness@fix/repair-path-liveness-check

The change re-checks ctx.sessions.get(id) at the top of prepareCore (inside the per-id serialize reservation) so the TOCTOU gap is closed. build:lib:host + typecheck:contracts-ready are green.

One thing I intentionally left as a note rather than claiming: the throw-vs-retry interaction with the coordinator-contract suite — prepare/load/inspect already check liveness and loop, so a throw from prepareCore needs to be reconciled with serialize/reserve retry semantics. If you have the environment, I'd welcome a run of coordinator-contract against this branch; otherwise I'll pick it up when I can.

Fixes #2 (seq-ownership) and #3 (reader self-heal) are still analysis-only in the patch queue.

[zoahdev]

Landed fix #1 (repair-path liveness) as a cherry-pick-ready branch:

zoahdev/deepseek-harness@fix/repair-path-liveness-check

The change re-checks ctx.sessions.get(id) at the top of prepareCore (inside the per-id serialize reservation) so the TOCTOU gap is closed. build:lib:host + typecheck:contracts-ready are green.

One thing I intentionally left as a note rather than claiming: the throw-vs-retry interaction with the coordinator-contract suite — prepare/load/inspect already check liveness and loop, so a throw from prepareCore needs to be reconciled with serialize/reserve retry semantics. If you have the environment, I'd welcome a run of coordinator-contract against this branch; otherwise I'll pick it up when I can.

Fixes #2 (seq-ownership) and #3 (reader self-heal) are still analysis-only in the patch queue.

[zoahdev]

Update: I ran the session-persistence-jsonl coordinator-contract suite against the branch myself — 151/151 passed (load/prepare/inspect/repair paths), so the throw-vs-retry concern I flagged earlier is resolved; the fix is runtime-verified, not just typecheck-green.

(sqlite suite is 99/100 — the one failure is a Windows symlink EPERM environment issue, unrelated.)

So fix #1 is now fully verified on my side. Remaining: #2 (seq-ownership) and #3 (reader self-heal).

[zoahdev]

One more finding while I was in the code — fix #2 (seq-ownership) is already substantially implemented, so it may be narrower than the family framing suggests:

• The live append path has a "Contiguity contract" check in appendCore (coordinator.ts ~699): every event's seq must equal state.cursor + i, else append seq mismatch.
• The repair path is guarded by isPreparedSourceCurrent (coordinator.ts ~974): readStoredRevision(id) === source.revision, so commitRepair is skipped if the durable log changed after prepareCore read it.

So the remaining gap is not "append/repair has no seq check" but specifically: commitRepair → backend appendLines writes the synthetic closers without re-asserting contiguity at write time. With fix #1 (liveness) + the revision guard, the realistic trigger for a seq collision is now cross-process and revision-stable — which is a much smaller surface.

Do you have a specific repro where the revision guard does not change but a writer still collides? If so, that's the exact place fix #2 should add a seq assertion; otherwise I'd fold #2 into a defensive assertion in commitPrepared rather than a separate patch.

[LengMu-Cloud]

Do you have a specific repro where the revision guard does not change but a writer still collides? If so, that's the exact place fix #2 should add a seq assertion; otherwise I'd fold #2 into a defensive assertion in commitPrepared rather than a separate patch.

Thanks for landing #1 and #3 so quickly!

On your question for #2 — I believe I have a real-world repro. Both of my corrupted logs came from dsh 0.1.0-rc.6 (npm global install). The installed coordinator already contains the revision guard (isPreparedSourceCurrent in commitPrepared) and the live-append seq contiguity check (append seq mismatch), yet the collision still happened.

In both logs the synthetic closers (step/end + turn/end {reason: interrupted}, timestamp reused from the last real event) sit immediately before the real events carrying the same seqs, followed by a contiguous tail. That matches the guard passing at check time (the live writer's bytes landed right after), then colliding at the commitRepair -> appendLines seam — exactly the write-time gap you identified. So I'd say #2 is a real patch: re-assert seq contiguity at write time in the repair append path.

If useful, I can post sanitized metadata samples (seq/type/time only, no conversation content) in this thread for the regression test. The raw logs contain personal conversation data, so I'd rather not post them publicly, but I can provide them privately if needed.

[zoahdev]

Fix #3 (reader self-heal) is also landed:

zoahdev/deepseek-harness@fix/session-log-synthetic-tail-self-heal

SessionLogScanner.consumeEventLine now detects the backwards-seq-right-after-synthetic-turn/end {interrupted} pattern and drops only the regenerable tail, then re-aligns with the real events. Verified: jsonl suite 152/152 (151 existing + 1 synthetic-tail-collision regression), build + typecheck green.

So the #2342 family now has two landed patches (#1 liveness, #3 reader self-heal) and #2 narrowed to a defensive seq assertion in commitPrepared (still waiting on a revision-stable repro from you, if one exists).