bug

[3272316784]

DSH会话日志恢复Bug上报.md

[zoahdev]

核验通过（对照 main/master HEAD 99f6f02 rc.7 TS 源码）——根因定位准确，这是崩溃恢复路径的双编号源竞态，比"纯编号 bug"更值得按一次事故级问题处理。

1. 你引用的机制在源码逐条成立：

• packages/core/session/src/repair.ts:27+：interruptedTurnClosers 按"sequences continue the log and timestamps reuse the last real event"合成缺失 closers（last.seq + 1 起）；
• packages/core/session/src/index.ts:539：this.firstLiveSeq = this.log.length；:565：get seq() { return this.log.length }——"seq = log.length 连续性契约"原文成立；
• packages/session/session-persistence/src/coordinator.ts:892-930：prepareCore 用 balanced = [...storedEvents, ...closers] 构造 Session（同进程内 seed 已含 closers）；
• coordinator.ts:945：commitRepair 把 closers 写进文件后 返回 undefined、强制重载（"reload the exact committed graph"）——设计上已防"同进程双编号"，所以你的双实例假设是正确方向：两个 harness 实例共享 $DSH_HOME，其一 commitRepair 落盘 216778-216781，另一实例用未含 closers 的 seed（log.length=216778）续写同一段编号；
• packages/session/session-persistence-jsonl/src/format.ts:347-370：consumeEventLine 检测到 gap 抛 seq gap in committed region，无恢复分支——永久 corrupt 成立。

2. 影响面补充： 这不是孤例。commitPrepared 的"修复后强制重载"意味着只要存在第二个读/写源（共享 $DSH_HOME 的并发实例、HMR/reload 的 adoptLivePrefix 路径 coordinator.ts:1301+），同号续写就可能发生。建议在修复前先确认 $DSH_HOME 是否有双实例并发（你的桌面端分发版场景正好命中）。

3. 三条修复方向的优先级（我的排序）：

1. 单一编号源（你的方案 3）——正解：closers 也走 Session.append，恢复与续写共用一个 Session 实例，双编号源从根上消失；
2. firstLiveSeq 按文件实际提交数（方案 1）——必要的防御：即使多实例，续写者的基数也应读"文件已提交事件数"而非内存 seed 长度；
3. scanner 可恢复路径（方案 2）——韧性兜底：本次 99.99% 数据完好却整体不可读，代价过高；建议"重编号后续段 + 标记修复 + 保留原文件备份"，与坏工件隔离族（[bug] SQLite scanRows torn-tail tolerance deletes valid events together with the bad row #675/[Bug Report] 单个会话日志损坏使 `session.list` 整体 500，Web 侧边栏全部会话消失且无界面提示 #1047/[BUG] 会话日志中一条 tool/result 引用了不存在的 call id，导致该会话所有请求被供应商 400 拒绝，永久不可用 #1593）的"隔离 + 可见"原则一致。

4. 家族归类： 这是家族 3（坏工件隔离）的"崩溃恢复"子族新成员，我把它并入图谱（#3232 + #1593 + #1047 同族）。

需要的话：我可以按你的字节级复现信息写一个回归测试骨架（crash tail → interruptedTurnClosers → 双实例模拟 → scanner 判定），或者等你提供脱敏日志后做一次独立复现验证。

[zoahdev]

按承诺补了回归测试骨架，已推送：

https://github.com/zoahdev/deepseek-harness/tree/test/session-crash-seq-overlap

packages/core/session/tests/repair.spec.ts 新增用例（基于你报告的字节级现场构造）：

• 崩溃尾（open turn/step + 悬空 tool call，最后真实 seq=2）→ interruptedTurnClosers 生成 closers seqs [3,4,5]；
• 双写者碰撞：未含 closers 的续写 seed（log.length=3）下一事件取 seq=3，与 closers[0] 重叠——钉住 bug #3232 的机制；
• 修复方向：含 closers 的 balanced seed 下一事件从 6 开始，严格位于 closers 之后——单一编号源不重叠。

验证：repair.spec.ts 12/12 通过（core/session 包内）；pre-push 全量 typecheck 过。测试只钉行为、不含修复——等你或其他人在修复方向落地后，这个用例的"碰撞段"应改为断言"不重叠"（届时续写 seed 必含已提交 closers 或 firstLiveSeq 按文件计数）。