[bug] 会话历史加载失败：崩溃恢复与残留执行流并发写同一日志，seq 重叠（corrupt session log: seq gap in committed region）

[Frosty-dust]

崩溃恢复写入的合成闭包事件，与仍存活的旧执行流写入的真实事件，共用 seq 200476–200479，导致会话历史加载失败。

环境

• @deepseek-ai/dsh-session-persistence-jsonl 0.1.0-rc.6（npm next，2026-08-13）
• Windows；存储格式 zstd JSONL，packChunks 开启

症状

打开会话时提示：

history unavailable for session "session-da9edcf9-…": Error: corrupt session log: seq gap in committed region at line 10170 (expected 200480, got 200476)（internal）

复现路径（据日志证据还原，未做最小确定性复现）

1. run_code → pwsh 工具调用执行中被强制结束/重启；日志已持久化到 tool/code-dispatch-start（seq 200475）。
2. 重启后的恢复流程合成 4 条闭包事件并写入日志：
   • tool/result（interrupted-tool-result-call_…-200476，TOOL_OUTCOME_UNKNOWN）
   • step/end
   • turn/end（interrupted）
   • session/end-seed
   • 对应 seq 200476–200479。
3. 约 119 秒后，残留的旧执行流把同一 rootCallId/subCallId 的真实执行结果再次追加到同一文件，但 seq 仍从 200476 开始（tool/code-dispatch → 真实 tool/result → step/end → step/start…）。
4. 解码器要求 events[i].seq === i，在 end-seed 之后发现回退，整段历史拒绝加载。

关键日志节选

L10165 seq=200474 tool/call              callId=call_00_wvO…
L10166 seq=200475 tool/code-dispatch-start
L10167 seq=200476 tool/result            interrupted-tool-result-…-200476 / TOOL_OUTCOME_UNKNOWN
L10168 seq=200477 step/end
L10169 seq=200478 turn/end               reason=interrupted
L10170 seq=200479 session/end-seed
L10171 seq=200476 tool/code-dispatch     ← 与 L10166 同一 subCallId，seq 回退
L10172 seq=200477 tool/result            ← 真实执行结果
L10173 seq=200478 step/end
L10174 seq=200479 step/start
L10175 seq=200480 assistant/chunk

物理层面对应：合成闭包位于 zstd 第 7791/7792 帧，真实续写从第 7793 帧开始。

影响

• 会话窗口永久显示“历史加载失败”，无法续写。
• 与 README 中“One live writer per session”限制直接冲突：恢复写者与旧执行流写者没有跨实例互斥。

临时修复（本地已验证）

删除 4 条过时合成闭包（物理上移除 2 个 zstd 帧）后，剩余 244,016 个逻辑事件用官方 decodeStorageRecord + Session.fromRestore 全量校验通过，历史完整恢复。

期望修复

1. 应用/进程级对同一会话强制单写者，恢复写者在写入闭包前确认旧写者已退出；
2. 或恢复流程以当前已持久化日志长度重新计算游标，而不是让旧执行流按过期游标续写；
3. 可选：解码器遇到“合成 interrupted-tool-result 被同一 callId 的真实 result 取代”模式时，自动丢弃过时闭包而不是整体拒绝加载。

关联

• 相关但不相同：[bug] After a force-kill of the DSH host (deadlocked agents) + restart, user input appears late or never - write-behind batching loses the un-flushed tail #483（force-kill 后 write-behind 尾部丢失）

[argszero]

逐条对着 master（47f943859b）核实完毕——机制完全成立，而且这是损坏家族里**第五种、也是第一个"恢复写者 vs 仍存活旧写者"**的样本。补充几个源码级细节：

机制确认（为什么必然碰撞，而不是竞态）

两条写路径的 next-seq 来源不同：

• 恢复路径：prepareCore（session-persistence/src/coordinator.ts:895-928）读取已持久化前缀 → interruptedTurnClosers（core/session/src/repair.ts:27）从 last.seq + 1（= 已持久化事件数 200476）合成 4 条闭包（tool/result（id 形如 interrupted-tool-result-{callId}-{seq}，与你日志逐字吻合）/ step/end / turn/end(interrupted) / session/end-seed）→ commitPrepared → commitRepair → appendLines。这条路径从头到尾没有任何"旧写者是否仍存活"的检查——它假定自己是唯一写者。
• 旧执行流：还活着的进程内存里 seq = this.log.length（core/session/src/index.ts:629）仍是 200476（它内存里就是这么多），真实结果 append 时直接复用 200476。

一个从持久化文件长度取游标，一个从过期内存长度取游标——只要两个写者同时存活，碰撞是确定性的，不是时序运气。你的 119 秒窗口说明这个窗口无界：旧流可以在任意时刻续写，恢复方无法预知。

解码器拒绝点也确认：session-persistence-jsonl/src/format.ts:355-372 committed-region 检查 event.seq !== this.events.length——累积到 200480（200476 持久化 + 4 闭包）时遇到回退的 200476，整段拒绝，报错与你完全一致。

家族定位

• seq 序号重复导致对话加载失败 #1333/BUG: 同一 DSH_HOME 下多进程并发写同一会话日志，导致 seq 重复、整段历史无法加载 #1452：跨进程并发写（两个写者，无互斥）——本贴是两个写者；
• Bug: corrupt session log after unclean exit — replayed events cause seq gap in committed region, history unrecoverable #1497：崩溃恢复重放（合成闭包 + session/end-seed 后旧游标续写）——本贴的 4 条闭包就是同一恢复路径；
• 本贴新维度：恢复写者 vs 根本没死的旧写者。Bug: corrupt session log after unclean exit — replayed events cause seq gap in committed region, history unrecoverable #1497 是同进程重启后内存游标重放；这里是旧进程全程存活还在写。你引用的 README "One live writer per session" 正是这条家族线从未被强制过的声明。

修复映射

1. 你的期望修复 #1（单写者强制）——刚在 [Bug] Cold history loading fully materializes large/corrupt logs and can stall the entire Web server #1550 有现成实现：wellorbetter 发布的 fork 补丁 fix/session-history-responsiveness（writer-lease.ts，基于原子 link() 的跨进程锁）在 appendBatch、repair、commitRepair 三处都加了 ensureWriterLease——恢复写者遇到同机存活 PID 会 fail-closed（抛 contention error，拒绝写）而非静默写坏。这正是"恢复写者在写闭包前确认旧写者已退出"的落地：旧进程没死 → 恢复失败并提示停止另一个 dsh 进程；旧进程已死 → 正常接管。README 声明从文档变成强制。我实跑了该补丁测试全绿（writer-lease 2/2、jsonl 152/152、zstd 81/81）。PR 通道重开后建议直接合并它作为本贴修复。
2. 期望修复 #2（按持久化长度重算游标）：治标不治本——解决"旧流下次启动时"的场景，但解决不了"旧流还活在内存里"的窗口；锁才是根本。
3. 期望修复 #3（解码器自动丢弃过时闭包）——不建议：format.ts:355 的 committed-region 检查是全损坏家族的完整性回退点，引入"识别过时闭包"启发式会开始掩盖真实损坏（与家族"严格检测 + 响亮失败 + 工具修复"的方向相悖）。而且离线侧已有对应工具：dsh-doctor S7（dsh-doctor: an offline diagnostic for the failure classes this community keeps reporting #1534，社区工具）检测的正是"end-seed 后回退重放"签名——你本地删除 4 条闭包恢复成功，正是 S7 的修复动作。
4. 你关联的 [bug] After a force-kill of the DSH host (deadlocked agents) + restart, user input appears late or never - write-behind batching loses the un-flushed tail #483（force-kill 后 write-behind 尾部丢失）是同一恢复路径的另一面：这次是尾部存活而恢复方不知道，上次是尾部丢失而恢复方补不上。两案共享"恢复方对旧写者状态一无所知"的根因。