DSH-BUG-REPORT-seq-gap-overlap

[zjs813-sudo]

[Bug Report] 会话中断恢复后合成收尾事件与续写事件 seq 重叠，导致日志损坏、历史无法加载

提交渠道：deepseek-ai/deepseek-harness GitHub Discussions（Bug Report 分类）
提交链接：https://github.com/deepseek-ai/deepseek-harness/discussions/new
本报告由实际日志分析 + 源码定位得出，证据如下。

环境

• 版本：@deepseek-ai/dsh 0.1.0-rc.6（npm 全局安装，桌面应用内嵌 dsh web 子进程）
• Node：v24.19.0
• 平台：Windows（Electron 桌面应用）
• 会话日志物理格式：session.jsonl.zstd（拼接 zstd 帧：头帧 + 每批事件一帧，packChunks 打包分片行）

现象

加载某个会话历史时失败，错误信息：

history unavailable for session "session-37374e34-...": Error: corrupt session log:
seq gap in committed region at line 9551 (expected 165985, got 165983)

读端校验器（dsh-session-persistence-jsonl 的 SessionLogScanner.consumeEventLine，lib/index.js:275-300）要求每个事件的 seq 从 0 严格连续递增；发现重叠即判定日志损坏并拒绝加载。该会话因此永久无法加载历史（无自动修复路径，只能手动改日志文件）。

日志证据：两个"边界事件"是崩溃恢复合成的，不是正常写入

损坏点前后（原始 JSONL 行号）：

行	事件	seq	time
9549	reasoning-chunks（turn 6 step 1，最后一段分片）	seq0=165958，含 25 个 chunk	time0=1786886027781
9550	step/end（turn 6 step 1）	165983	1786886027971
9551	turn/end（turn 6, reason:{kind:"interrupted"}）	165984	1786886027971
9552	reasoning-chunks（同一 turn 6 step 1，同一段推理文本续写）	seq0=165983（重叠！）	time0=1786886028008
…	恢复后一直续写，seq 165983→183873，内部连续
10477	turn/end（turn 6, reason:{kind:"completed"}）	183873	1786886243823

三点吻合 @deepseek-ai/dsh-session 的 interruptedTurnClosers()（lib/types/repair.js:21-125）：

1. 事件形状：该函数正是"先补 step/end（若 step 未关闭），再补 turn/end { reason: { kind: 'interrupted' } }"（repair.js:120-123）；
2. 时间戳：注释明确"合成事件复用最后一个真实事件的时间戳"（repair.js:76-80）。验证：raw 9549 最后 chunk 的 time = time0(1786886027781) + Σdt(190) = 1786886027971，与两个合成事件 time 完全一致；
3. seq：let seq = last.seq + 1（repair.js:79），即 165983。

即：turn 6 的流被中断后，durable 日志尾部留下一个未关闭的 turn（最后真实事件 seq 165982）；某次恢复/冷加载路径（dsh-session-persistence 的 prepareCore → interruptedTurnClosers → commitRepair）检测到未关闭 turn，向文件追加了这两个合成收尾事件（seq 165983/165984）。随后同一 turn 在 37ms 后恢复续写（同一段推理文本无 user/message 隔断，最终 turn 6 completed），但续写事件的 seq 从 165983 重新开始——与文件中已有的两个事件重叠。

根因：写端两条路径的 seq 状态不同步

• 崩溃恢复路径只写文件、不推进内存游标：commitPrepared（dsh-session-persistence/lib/index.js:1019-1028）在 tornMarker/closers 非空时调用 backend.commitRepair(...) 后直接 return，没有 this.states.set / cursor 推进；commitRepair（dsh-session-persistence-jsonl/lib/index.js:1031-1035）也只做 truncate + appendLines，纯文件操作。
• 实时写入路径只校验内存游标：appendCore（dsh-session-persistence/lib/index.js:829-835）检查 event.seq !== state.cursor + i，但 state.cursor 是内存值，落后于文件已提交长度（165985），所以续写事件 165983 通过了校验。
• 读端校验严格、写端不严格：读端 SessionLogScanner 要求 seq 全局连续，重叠即抛错；写端只与内存游标比对，检测不到与文件的重叠。
• 正常情况下有防护：adoptLivePrefix（lib/index.js:1285-1302）的 seedCoversPrefix 会拒绝"live 种子不覆盖已持久化前缀"的情况——但本次流程中恢复续写未走该防护（很可能是同一进程内 live Session 未释放、写路径直接续写），故未被拦截。

影响

• 触发条件：会话运行中 turn 被瞬时中断（流错误/超时/内嵌 harness 重启等），随后同一 turn 恢复续写。日志尾部出现 seq 重叠 → 该会话历史永久不可加载，且无自动修复。
• 已损坏会话只能手动修复：删除两个合成收尾事件（step/end、turn/end interrupted）后，恢复段恰好从 seq 165983 无缝衔接，日志即恢复连续（本次修复后 183874 事件、seq 0..183873 连续、turn/step 边界平衡，内容零丢失）。

建议修复

1. 提交修复（commitRepair）后同步推进 coordinator 的 durable cursor / 清掉陈旧 state，使后续 append 的校验基准与文件已提交长度一致；或
2. 写端校验改为与文件已提交长度对齐（append 前读取 committed 前缀长度，或对落后事件重新编号为 committedLength + i），而不是只对内存游标做弱校验；或
3. 拒绝续写：当 live 写路径的 next-seq 与 durable 尾部不一致时抛错（把 seedCoversPrefix 的防护扩展到 seq 对齐），而不是静默写出重叠事件。

附件 (Attachments)

见同目录 DSH-BUG-REPORT-attachments/(说明见其中 README.md):

文件	说明
corrupt-log-session-37374e34-e3c7-4a0e-a67b-5d1e2522d403.jsonl.zstd	原始损坏日志(2.9 MB,未修改的逐字节副本),可直接复现报错
repair-seq-gap.js	自包含修复脚本(仅 Node 内置模块),修复"seq 向后重叠"这一类损坏
repaired-log-session-37374e34.jsonl.zstd	修复结果(1.2 MB,与线上已部署文件 SHA-256 一致,已用真实 readPrefix 验证)

备注

• 会话 id：session-37374e34-e3c7-4a0e-a67b-5d1e2522d403
• 损坏日志备份：~/.dsh/sessions/--C-Users-...--/session-37374e34-.../session.jsonl.zstd.corrupt-bak
  Uploading DSH-BUG-REPORT-attachments.zip…

[MedicineKing]

同簇问题（同 #1497：seq 重叠/回退导致 committed 区拒读）。两条不丢历史的解法（官方未打补丁 0.1.1-rc.2 实测：931,455 事件零 seq gap，Session.fromRestore 通过）：

1. 读端容错补丁：SessionLogScanner 遇到已消费过的旧 seq（回退/重复/重叠段）时改为跳过而不是整体拒读——磁盘上的所有已提交内容零裁切保留。合成收尾与续写事件 seq 重叠——同上，读端容忍。
2. 零安装 CLI（dsh-corrupt-session-repair）：node dsh-corrupt-session-repair.mjs 扫描（只读）→ fix 预览 → fix --apply（先写 .bak.zstd；写回与官方同款 checksum 帧——header 单独一帧，assertZstdHeaderFrame 直接接受）。真跳号/物理损坏只报告、绝不重写。

已坏在磁盘上就用 2；想让未来崩溃也看不见就上 1。

[173787247]

安装 / 环境（「DSH-BUG-REPORT-seq-gap-overlap」）

这类问题优先排除：源/代理、运行时版本、半残缓存。

1. 对齐仓库要求的 Node / Python，不要系统 Python 和 venv 混用。
2. Windows + WSL 或开了代理：Node 24 需要 NODE_USE_ENV_PROXY=1，本机服务加 NO_PROXY=127.0.0.1,localhost。依赖尽量装在 Linux 文件系统，不要放 /mnt/c。
3. npx 卡住就换 pnpm / uv，清掉坏的 node_modules 再装一次。
4. 日志里的 Error: corrupt session log: 建议先原样搜本仓 Issues。

补充：系统、node -v/python -V、第一段报错（不用整棵 npm 树）。

[po-et]

你手工删掉两条合成收尾事件、让真实续写接回去的做法，我做成了工具：https://github.com/po-et/dsh-session-rescue 。和楼上 MedicineKing 的工具路线基本一样（扫描、预览、--apply 先备份、header 单独一帧、真跳号只报不改），区别就在你这个场景：committed 尾部是合成收尾块、真实续写和它撞号时，rescue 删收尾块、保续写，而不是保先提交的那一侧；写之前还会查 sourceEventSeqs 有没有悬空，有就拒绝。npx github:po-et/dsh-session-rescue repair <id> 先看计划再 --apply。你那份 18 万事件的日志要是还在，拿它跑一遍就是最好的测试。