[Bug] 工具被中断后会话日志写入重复 seq，导致会话损坏无法恢复（resume 报 seq gap）

[chenzhexii]

[Bug] 工具被中断后会话日志写入重复 seq，导致会话损坏无法恢复（resume 报 seq gap）

环境（本机实测）：@deepseek-ai/dsh 0.1.0-rc.6，npm 全局安装于 C:\Users\Administrator\AppData\Roaming\npm；Windows 10 专业版 22H2（Build 19045，64 位）；C 盘与 D 盘均为 NTFS；会话日志位于 C:\Users\Administrator\.dsh\sessions\，存储格式为 JSONL + zstd 多帧。

现象（观察事实）

dsh 恢复（resume）会话时失败，报错原文：

corrupt session log: seq gap in committed region at line 8895 (expected 147797, got 147793) (internal)

（说明：错误信息中的行号 8895 是扫描器的事件行计数，不含 header 行；对应日志文件的物理第 8896 行。）

检查日志文件确认：文件中存在两套 seq 完全相同的事件（见下文"补充信息"），seq 从 147797 回退到 147793，扫描器据此判定日志损坏。

复现步骤

1. 让 agent 发起一个工具调用（本次场景中为 pwsh 命令）
2. 在工具执行期间中断（interrupt）agent
3. 中断后会话继续运行（日志可见随后进入下一个 step）
4. 之后尝试恢复（resume）该会话 → 失败，报上述错误

实际结果

• 日志中先出现中断占位事件（seq 147793–147796）：tool/result（消息 id 带 interrupted-tool-result- 前缀）、step/end、turn/end（reason: interrupted）、session/end-seed
• 其后又追加了**使用相同 seq（147793–147796）**的真实事件：tool/result（同一 callId 的真实结果）、step/end、step/start、assistant/chunk
• 再往后的事件从 seq 147797 继续
• 由于 JSONL 是 append-only 追加写入，物理文件中两套 seq 相同的事件并存，扫描器在真实事件块首行发现期望 seq 147797 而实际为 147793，判定日志损坏，resume 失败

预期结果

中断后续写的事件 seq 应与已提交日志前缀严格连续；会话在任何时候都应可被加载，而不是因 seq 重叠整体拒绝恢复。

环境与相关代码

• @deepseek-ai/dsh 0.1.0-rc.6（npm 全局安装，Windows 10 专业版 22H2 Build 19045，NTFS）
• 持久化后端：dsh-session-persistence-jsonl（zstd 多帧，每帧含整数条完整 JSONL 记录）
• 相关代码位置（均已核对源码）：
  • dsh-session-persistence-jsonl/lib/index.js → SessionLogScanner.consumeEventLine：seq 连续性校验；遇到缺口时记录 issue，若当前行或后续行解码出 turn/end 事件则抛错
  • dsh-session/lib/index.js → interruptedTurnClosers：为不平衡的 turn 生成合成关闭事件（含 interrupted-tool-result-* 占位），seq 从 last.seq + 1 开始递增
  • dsh-session-persistence/lib/index.js → prepareCore / commitPrepared / commitRepair：恢复准备阶段生成占位事件并追加写入持久层

验收条件

1. 上述复现路径下会话可正常 resume，且日志 seq 保持连续
2. 写入路径在检测到新事件 seq 与已提交日志前缀重叠时，能够告警或先截断/替换占位段，而不是追加造成 seq 重复
3. 扫描器对 seq 重叠/回退有可恢复的处理路径，而非整个会话拒绝加载

补充信息

损坏日志中的事件序列（seq 脱敏为相对值 a，与真实日志逐条对应）

seq a   tool/result     # interrupted 占位，消息 id = "interrupted-tool-result-<callId>-a"
seq a+1 step/end
seq a+2 turn/end        # reason: interrupted
seq a+3 session/end-seed
seq a   tool/result     # 同一 callId 的真实结果，与占位 seq 重复 ← 回退点
seq a+1 step/end        # 重复
seq a+2 step/start      # 重复
seq a+3 assistant/chunk # 重复
seq a+4 ...             # 后续事件从 a+4 继续，与期望一致

已实测的恢复验证（供修复参考）

用 DSH 自身的解码逻辑（decodeStorageRecord + seq 校验）及 JsonlSessionPersistence.readPrefix 实测：删除中断占位块（tool/result(interrupted) → step/end → turn/end(interrupted) → session/end-seed）并保留真实事件块后，seq 自动恢复连续，共 149458 个事件全部通过校验，会话可正常加载，无需重新编号。

分析（推断，非实测）

两套事件的 seq 完全一致、且对应同一工具调用的同一位置，推测中断占位事件与真实事件互为"替代"关系，但被同时物理追加进了 append-only 日志。此推断仅基于上述日志证据，供维护者定位参考。