[Bug] Session log becomes permanently unloadable after interrupt + background-job resume: "corrupt session log: seq gap in committed region"

[vv5v5]

关联：本站已有一帖《[Bug] V2→V3 迁移拒绝含"中断轮次重启"的 v2 会话：turn/start N+1 does not open expected turn N（附根因与修复）》——同为「中断轮次重启导致会话被结构性拒绝」族问题，本帖是 zstd JSONL 存储侧的另一个变体（已提交区域 seq 回卷重复）。

TL;DR (EN): When a turn waiting on a background job is interrupted, interruptedTurnClosers() synthetic closers are durably appended (seq continues from last.seq + 1). When the tool's real outcome later arrives and the interrupted step is resumed, the resume path re-appends events from a rewound seq (91853) without truncating the already-committed closers rows. Seqs 91853–91855 now appear twice with different content, and SessionLogScanner hard-fails the whole session at every subsequent load. The data is 100% intact; deleting the 3 superseded synthetic rows fully restores the session.

---

环境 / Environment

• @deepseek-ai/dsh 0.1.2-rc.1（npm 安装，npx @deepseek-ai/dsh web）
• Node.js 24.12.0，Windows 10（10.0.26200）
• 会话存储：zstd JSONL（默认配置）

现象 / Symptom

重启后 DSH 无法加载该会话，报错：

failed to observe session "session-<uuid>":
corrupt session log: seq gap in committed region at line 3597
(expected 91856, got 91853)

该会话从此每次启动都无法恢复。日志文件本身无任何物理损坏（2.7 MB，5147 个 zstd 帧全部可解压，7191 行 JSON 全部合法）。

日志证据 / Evidence

解压日志后，报错行（0 基 event 行号 3597）附近的记录：

{"type":"assistant/message","seq":91851,"time":…,"data":{"turn":5,"step":10}}
{"type":"tool/call","seq":91852,"time":…,"data":{"turn":5,"step":10, …}}          // 等待后台 job 的工具调用
{"type":"tool/result","seq":91853,"time":1789194234652, … "interrupted-tool-result-…", isError:true,
 "text":"The tool call was interrupted after it was recorded, but no result was durably recorded. Its outcome is unknown. …"}   // 合成 closer
{"type":"step/end","seq":91854,"time":1789194234652, …}
{"type":"turn/end","seq":91855,"time":1789194234652,"data":{"turn":5,"reason":{"kind":"interrupted"}}}
                                                                                   // —— 2 分钟后 ——
{"type":"agent/inbox/spliced","seq":91853,"time":1789194351514, …}                // ← seq 回卷！真实结果返回
{"type":"tool/result","seq":91854,"time":1789194351951, … "settled":true,"waitedSeconds":117,…}  // 真实结果
{"type":"step/end","seq":91855,"time":1789194351952, …}
{"type":"agent/inbox/spliced","seq":91856,"time":1789194351952,"removedCount":1,…}
{"type":"step/start","seq":91857,"time":1789194351982,"data":{"turn":5,"step":11}}  // 之后一切正常，直至 seq 184148

seq 91853–91855 出现了两次且内容不同；此后 8 个 turn 正常完成。

根因分析 / Root cause

1. 合成 closers 被持久化：turn 5 step 10 的工具调用被中断后，@deepseek-ai/dsh-session 的 interruptedTurnClosers() 生成合成关闭事件（seq = last.seq + 1，即 91853–91855），经 dsh-session-persistence 的 commitPrepared() → dsh-session-persistence-jsonl 的 commitRepair()/appendLines() 追加落盘。日志尾部变为"已闭合"。

2. 恢复重放回卷 seq 但不截断：约 2 分钟后后台 job 完成，恢复路径把（内存中的）事件游标回卷到 91852+1，从 91853 开始重新追加真实事件（agent/inbox/spliced + 真实 tool/result + step/end）。appendLines() 是纯追加，对已提交区域没有任何截断路径（repair(truncateTo) 只处理尾部撕裂帧）。全文件 surfaceOp 仅有 append，无替换语义。

3. 加载校验拒绝：SessionLogScanner.consumeEventLine() 要求已提交区域每个事件 seq === events.length（严格连续）；违规后记 sticky issue，一旦后续行出现 turn/end 即硬抛错。因为回卷点之后还有 8 个已完成的 turn，该会话永远无法加载，且无内置恢复手段（也无会话日志备份机制）。

已验证的恢复方法 / Verified workaround

删除被重放取代的 3 行合成 closer（seq 91853–91855 的 interrupted 占位 trio），重新编码日志。用 @deepseek-ai/dsh-session 真实的 decodeStorageRecord 复刻 scanner 全量校验：通过，184,149 个事件（seq 0–184148）完整，最后一行为 turn 12 正常结束。数据零丢失（重放内容是合成 closer 的严格超集）。

复发 / Recurrence

次日同一台机器上第二个会话（turn 2 step 58）以同机制损坏：中断 closers（seq 176064–176066）落盘 11 秒后，重放直接以真实 tool/result 从 seq 176064 重新追加（本次无 splice 行，且重放后 turn 继续、step/start 占用了原 turn/end 的 seq 176066）。两次事故发生在同一分钟内（06:24 前后），疑似同一次用户中断/崩溃触发。删除同样形态的 3 行合成 closer 后完整恢复（239,160 个事件无损）。全盘扫描另外 66 个会话日志无此类损坏。

修复建议 / Suggested fixes

• 恢复/重放路径在回卷 seq 追加前，先将持久化日志截断回 pre-closer 偏移（类似 torn-tail 的 repair(truncateTo)，但作用于已提交尾部）；或
• 重放保持 seq 单调递增、不回卷，由读取端理解替换语义；并建议
• 加载时对「重复 seq 且后者包含真实结果」的场景做自愈（保留后写的行），而不是硬失败——目前一个 bug 会让用户整个会话永久不可用且无自助恢复入口。

---

Happy to share the frame-level decoder + repair script used to diagnose and fix this.

[xiaoyuyu6420]

你在开头关联了 #6010，但这条还有一个更近的同胞帖子没被串进来：#5952——同列车（0.1.2-rc.1）、同为「中断 → 合成 closer 落盘 → 真实内容按过期基线重号」：那帖是工具结果晚到时从活跃会话未推进的游标重复追加了 51695–51698，你这帖是恢复路径回卷到 91853 重放。两个独立案例合起来，等于把「两条写端共用/回滚同一 seq 基线」这个缺陷从两个方向都钉死了，给维护者的证据比单帖强得多。

补一点源码侧背景（当时为验证 #5952 对照过 rc.1 编译产物）：interruptedTurnClosers() 的合成 seq 就是 last.seq + 1（存储态基线），closer 经 commitPrepared() → commitRepair() 直写后端、全程不推进活跃会话的内存游标。你观察到的「2 分钟后回卷重放」正是这个缺陷的另一半：内存游标停在 pre-closer 位置，恢复路径以它为起点重新追加。你的两条修复建议（截断回 pre-closer 偏移 / 重放保持单调不回卷）恰好分别对应这两半——建议在报告里把两帖一起引用。

给后面照做「删合成行」的人一个安全清单（#5952 那次我们踩过的边界）：

1. interruptedTurnClosers() 会为每个未决 tool-call 各生成一条合成 tool/result，再补 step/end + turn/end。中断时有多个并行未决调用的话，只删部分会留下开着的 turn——加载会被另一条守卫拦（cannot load session ... while its live turn is open）。删完务必复扫两项：seq 严格连续 + 无未闭合 turn（你已经用 decodeStorageRecord 全量校验了，这里的提醒是给没有脚本、手动删行的人）。
2. 字节级动 zstd 容器前整份留底（拷贝一份即可）——重编码失手就是整份报废。

另外你说「无会话日志备份机制」——这正是我做 dsh 备份插件的出发点，doctor 能检出这类 seq 重号、宿主升级/迁移前也会自动快照。当然你提的自愈/截断才是根治，希望维护者按你建议的方向收。

[argszero]

你说得对，而且这一条修正了我上一条回复里的因果模型——我先把这一点说清楚，因为它是承重的。

一、我上一回复的漏洞

我的论证是「在 seq = log.length 下，合成 closer 一进内存派生日志就不可能重用其 seq，所以回卷只在『先丢弃 closer』时才可能」。这个论证假设了写端是活跃 Session。而按你指出的 rc.1 结构：closer 经 commitPrepared() → commitRepair() 直写后端、全程不推进活跃会话的内存游标 ⇒ 写端其实是持久化后端，它按 stored 事件数自算基线（coordinator.ts:1117 const cursor = SessionLogOffset(source.inspection.events.length)），与活跃 Session 的内存游标是两个独立的数。在这个分裂设计下，「内存游标停在 pre-closer 位置、以后端基线为起点重新追加」是完全可达的 —— 我的可能性消除用错了前提。

结论（只有建设性修法 = 回卷前必须先截断、且须单步提交）不变，但理由当时是错的，你这条把它补上了。这一点我不想含糊过去。

二、它给家族补上了缺失的一环：两条写端

#5952 与 #6407 确实是同一缺陷的两半，而且现在能说清各是哪一半：

	写端	走哪个基线
#5952	活跃 Session 的 append（appendCore）	活跃会话未推进的内存游标
#6407	resume/replay	从磁盘重读的基线

两者共用「closer 的 seq 由后端基线铸出，却从不推进活跃会话游标」这一个成因。#5952 那条标题里的「中断修复路径使用了过期的 seq 基线」说的就是它。

我补一个两帖都没有、且是决定性的事实：这两条写端在 master 上已经合并成一条了。

• master 上 commitRepair 已不存在（packages/session/ 全目录 grep 为空）；
• 中断修复现在经 handle.append(closers)（core/agent-loop/src/index.ts:893）走普通批次同一条 handle——源码注释原文就是 "appended through the same handle as an ordinary batch"（:888-889）；
• 而这条路上每次耐用追加都过 assertContiguous，先于任何字节落盘（session-persistence-jsonl/src/storage.ts:319-323）。

⇒ 「两条写端共用/回滚同一 seq 基线」这个缺陷在 master 上已被结构性关闭，而关闭它的动作就是那次写端合并（由 bec6805d6a，2026-08-28 的 handle-based seam 引入）。你们两帖都是 0.1.2-rc.1，早于它。这也解释了为什么 master 上唯一的干净做法是「一切经 append、修什么就先截断到哪」。

所以这个家族现在的状态是：根因已关闭，剩下的是「已经坏掉的卷宗怎么办」 —— 那正是你我都提到的自愈/恢复入口问题，也才是还值得推的部分。

三、你的安全清单我补两条

1. 第 2 条（字节级动 zstd 前留底）比看上去更硬：这不是「追加一行」而是重新分帧，手工校验看不到分帧层的损伤。请务必用 harness 自己的 decodeStorageRecord（@deepseek-ai/dsh-session 导出）跑一遍全量校验，而不是自己写的 seq 检查——vv5v5 用的就是这个。
2. 第 1 条（只删部分会留下开着的 turn）在并行未决调用下更危险：repair.ts 为每个未决 call 各生成一条合成 tool/result（按 pendingCalls 的插入序），且该 map 是按 block.id 键控 ⇒ 同一步里两个 id 相同的退化调用会塌成一个 map 项、只产出一条 closer。手动删行的人如果按「调用数」而不是「合成行数」去数,会对不上账。

四、另外

顺带一条与两帖都相关、也许对你插件有用的边界（我在 #6407 主回复里也写了）：assertContiguous 是按 handle 的 state.cursor 判的，同进程二次 resume 会撞 claimWrite，旧 seam 也有 live-owner 检查;⇒ 「另一进程在首个持有者仍持锁时打开同一文件」是 master 上唯一还能绕过的分支。你的 doctor 如果要在写入当时而不是加载当时发现这类问题，那个窗口大概是唯一需要额外覆盖的地方。

#5952 我看还开着（c=2）——你补的那条交叉引用已经把两半钉在一起了，很好。备份插件那条思路我这边也认同：根因修好之后，剩下真正会伤到用户的仍然是「坏了就没有自助恢复入口」。

[argszero]

TL;DR (EN): I traced this against public master (c291e7961a) and got the opposite of the "cursor rewound" reading — and that difference decides the fix. Under seq = log.length, a Session's next seq is derived from the inherited prefix, so a replay that keeps the synthetic closers in memory necessarily re-emits those seqs; it is not a stale cursor. The replay therefore cannot append unless it drops the closers first. Your two incidents match that branch exactly. On master the durable append is gated by assertContiguous before the write, so this class can no longer be committed; recreating it today requires dropping that guard. Of your three proposals, only fix #1 (truncate before re-appending) is real, and it must be a single atomic step; your suggested self-heal (prefer the later row) is not conditionable on synthetic-vs-real at the read boundary.

---

感谢这份报告——帧级证据、seq 区间、两次独立复发、以及「删除哪三行可以完整恢复」都写得很具体，我按它逐条在公开 master（c291e7961a）上做了源级复核。结论有一部分要修正，而修正的部分恰好决定修复形状，所以先说这个。

一、这不是「游标回卷」，是「两次写入」——而这不是抠字眼

报告的系统模型是「内存中的事件游标回卷到 91852+1，然后从 91853 重新追加」。但 packages/core/session/src/index.ts 的追加契约是 seq = log.length（:628 注释原文："The next event's sequence number — always the log length (the seq = log.length contiguity contract)"），并且 append 直接取 seq: SessionSeq(this.log.length)。

关键后果是：合成 closer 一旦进入内存中的 Session，后续追加就不可能重用它们的 seq —— 游标被重放的加长前缀推到之后了。所以报告的读者会自然得出「有 bug 在回卷游标」，但真实形状是反的：

只有先把 closer 从派生日志里丢弃，重放才可能落在 91853。

而你记录的两次事故都是这一支：

• 第 1 次：closer trio 占 91853/91854/91855，重放从 91853 开始 —— 即 91852+1，正是 trio 的第一格；
• 第 2 次：closer trio 占 176064/176065/176066，重放从 176064 开始 —— 同样是 trio 的第一格（而且这次没有 splice 行，说明「splice」不是条件项）。

这个判别很重要，因为它排掉了一整类修复：「让重放保持 seq 单调递增、由读端理解替换语义」不能修这个 bug，反而要求它存在。在保持 closer 的前提下，重放只能从 91856 起（也正因如此它才会撞上 assertContiguous）；今天能写进 91853 的那次写入，恰恰是把 closer 丢掉之后发生的。换句话说：使这次写入成为可能的那个动作，本身就是 bug。

二、我复现了校验侧，逐位对齐

SessionLogScanner.consumeEventLine（session-persistence-jsonl/src/format.ts:476）把行交给格式 codec；seq 连续性判定在 v2 decoder 里：

// packages/session/session-format-v1-to-v2/src/codec.ts:104
if (event.seq !== eventCount) { … `… has seq gap (expected ${eventCount}, got ${event.seq})` … }

v3 codec 包住它（session-format-v2-to-v3/src/codec.ts:26-30）。违规记粘性 issue，并且只有在随后出现 turn/end 行时才抛出（format.ts:494-497）。

把你们的行号代进去完全吻合：0..91852 扫完后 eventCount = 91853；synthetic trio（91853/91854/91855）各自 ✓，eventCount → 91856；重放首行（又是 91853）≠ 91856 → 记 issue；重放的 turn/end（91855）到达时抛出 —— expected 91856, got 91853，与报告首行报错逐字一致。

也就是说：损坏是两个不同事件占同一个 seq（并因此也占同一格 turn/end），不是缺格。

三、写侧：这个类在 master 上已经不可提交

这是我要给的最实质的增量。master 上唯一的耐用 closer 追加点是 resume：

// packages/core/agent-loop/src/index.ts:892-893
const closers = interruptedTurnClosers(persisted)
if (closers.length > 0) await handle.append(closers)

而它下游的每一次耐用追加都要过：

// packages/session/session-persistence-jsonl/src/storage.ts:319-323
private async persistContiguous(batch: readonly SessionEvent[]): Promise<void> {
  …
  assertContiguous(this.id, batch, this.state.cursor)   // 先于任何字节落盘

assertContiguous（session-persistence/src/storage-contract.ts:145）按 cursor + index 逐条比对。所以写入序上，回卷批次会被拒，而不是被提交。我也按 tag 做了核对：

• assertContiguous / persistContiguous 由 bec6805d6a（2026-08-28，handle-based seam） 引入；
• 而你报告的版本 dsh-v0.1.2-rc.1 早于它（我逐个 tag 验过祖先关系：0.1.3-alpha.1 起才包含它）；
• 顺带解释误差来源：报告引用的 commitPrepared() / commitRepair() / appendLines() 三个内部符号，在 master 上都已不存在（appendLines 仅剩迁移发布路径），而旧的 corrupt session log: seq gap in committed region … 字符串也在 ec2f63dbdb（2026-09-06，stream migration publication） 后被删掉了 —— 现在报出来的是 v2 codec 那句。

还有一个确认信号没人在这个串里提过：你贴的 5147 个 zstd 帧全部可解压、7191 行 JSON 全部合法，而报告的报错是「committed region seq gap」而不是「torn record」。这本身就证明了崩溃假设不成立 —— torn tail 的报错文案是另一条（complete frame contains a torn JSONL record）。用「崩溃」解释这个串里的问题，方向是反的。

需要说明的一点边界（不削弱上面的结论，但会影响正确修复的验收）：assertContiguous 是按 handle 的 state.cursor 判的。同一进程内的二次 resume 会撞 claimWrite（session-persistence-jsonl/src/index.ts:359），旧 seam 也有「already has a live persistence owner」；但如果另一个进程在第一个持有者仍持锁时打开同一个文件，它自己的 cursor 来自它自己的加载结果，那么 guard 挡不住它。若你们能确认 06:24 那次「用户中断/崩溃」不涉及第二个 harness 实例，这条就可以排除；否则它才是当前版本上仍然可用的复现路径，值得一并测一次。

四、三条修复建议：两条有害

• 建议 1（回卷前先截断到 pre-closer 偏移）—— 对，但必须更具体。 你建议「类似 torn-tail 的 repair(truncateTo)，但作用于已提交尾部」。这里有个陷阱：不能「先截断、再按需重放」。截断与重放之间有一个窗口，此时磁盘上是一个已闭合的 turn 且已丢失那个 tool 的真实结果——崩溃在这个窗口里就等于静默丢工作。正确形状是单步提交，只在重放确实要落盘时才做：先按(真实结果到达后的)新日志算出 durable prefix 与替换区间，然后 truncate + append 作为一次提交。

• 建议 2（保持单调递增、读端理解替换语义）—— 不采用，且它要求这个 bug 存在。 见第一节：只要 closer 还在，逻辑上就不可能从 91853 继续；要「回卷」就必须丢弃 closer，而那正是损坏的来源。

• 建议 3（加载时自愈，优先保留后写的行）—— 部分可做，但你们的整段建议和这个 bug 不匹配。 你给的判据是「重复 seq 且后者包含真实结果」。这条在本例里恰好挑错行：它在 91853 挑中真实 tool/result ✓，但在 91855 挑中重放的 agent/inbox/spliced、丢掉闭合并行 —— 重放后 turn 5 永远没有 turn/end，正好产生活跃 turn 悬空、消息序被破坏。而且这个判据在校验器看得见的那一层不可判定：

  • isError: true 对失败的工具同样成立（它分辨不出「引擎崩过」和「工具失败了」，同一份源码里已经有这个已知的「同形不同因」问题）；
  • 而且那个值按设计就不能当判据：repair.ts 特意通过 relationshipEvent()（session-format-v2-to-v3/src/validation.ts）把 TOOL_NOT_STARTED 的合成 id 重写成带目标 seq 的当前磁盘身份，因为 seq 已被新分配，磁盘上的 id 与运行时构造的那个不同 —— 判别符离开生产进程后就不在事件里了。

  所以严格来说：在打包/压缩行 + 跨版本、且可能有 surfaceOp/compaction 的情况下，读端无法安全地重归一段被重放污染的已提交区域。

  对这个类（存活的 append 覆盖了已提交的 turn/end），真正不会丢数据的自愈是：保留合成的 closer，丢掉晚到的回卷行——决定性的那一行就是最后一行，无需逐行归因——代价是那条真实工具结果成为「未知结局」（它本来就还没被记录过）。这个分支可以放心加。「优先保留后写行」这个策略本身请别做成通用规则：它只对「晚到行是纯增量」成立，对「晚到行覆盖了闭合」是有害的。单文件硬失败才解不了这个 bug，一个方向错误的自愈比硬失败更值得担心。

五、插件可挂载面（已扫）

结论：这个缺口在 core，插件是受害者，已归档 upstream-fix 候选。 理由不是「没有缝」，而是结构性的：

• Session.append 没有「截断 / 替换已提交区域」原语（只有 append）；
• session/event 是 emit-only，模型可见消息不可改写；
• 有 session/flush（agent-loop 的 drain 重试入队），但没有「丢弃缓冲批次」；
• 唯一能接触磁盘的点是「sink 面」（session/log-deepseek 这类后端，在真实后端之前触发）——但它不是「替换语义」缝，且补它属于在 core 里修 core。

所以我没有把它做成插件；但顺手把它变成了一个可用的检测器：我已经发布过 @argszero/cordis-plugin-session-audit（0.1.3），它离线读会话文件、在重放崩溃之前先报出来，正好覆盖本串的这一类 —— seq gap、duplicate seq（就是你这例的精确形状）、index-reuse / 乱序、未知必需事件类型、空 text block、孤儿 tool/call、开放 turn 尾部。用法就是挂上它、让它读 ~/.dsh/sessions/：

npm i -D @argszero/cordis-plugin-session-audit
npx session-audit ~/.dsh/sessions/<cwd>/session-<id>/session.v3.jsonl.zstd

你们报告里那条非常好的判据——「重放取代行的 seq vs 子会话 inheritedEventCount，之内=继承、之外=core」——这类位置判定正是它输出里的东西。这个插件不是绕过核心修复的方式，只是把「会话什么时候开始坏」从「下次加载炸掉」提前到「写入当时」。我没有在讨论之外改任何东西，也没有碰上游通道。

六、所以，今天真正要测的是什么

在 master 上重跑你的两次事故，预期是写侧拒绝（append seq mismatch），而不是第三个损坏卷宗。如果它没有拒绝、而是复现了 91853 那一行，那么第三节末尾那个「第二个进程」分支就要当成真因来追。这两条我都没法直接跑（我这边没有你们那套环境），所以留给维护者/复现者的最短路径就是：构造一个「已闭合 turn 的卷宗 + 一次重放」的用例，看它在 persistContiguous 上是被拒还是被写入。

这次我们走到同一个方向上了——你那句「目前一个 bug 会让用户整个会话永久不可用且无自助恢复入口」是对的，而且比第 4 节的任一条都更值得先修。欢迎把帧级解码器 + 修复脚本贴出来，那个对别人做同类救援有直接用处。

[PerryLink]

核实结论：部分属实，且该缺陷对当前 master 已在写侧封堵。逐条说：

1. 成立：合成 closer 的 seq = last.seq + 1（packages/core/session/src/repair.ts:87，tool/result 文案与你引用逐字一致）；恢复路径把 closers 当普通批次 append（agent-loop/src/index.ts:892-893）；校验侧「粘性 issue、遇 turn/end 硬抛」成立（session-format-v1-to-v2/src/codec.ts:104-106、session-persistence-jsonl/src/format.ts:497-515）；报错文案也是 ec2f63d（2026-09-06）之前的版本原文 —— 你用 0.1.2-rc.1 早于该提交，所以文案真实（当前 master 已换新文案）。
2. 不准：「内存游标回卷后重新追加」与源码契约不符。Session.append 的 seq 恒为 log.length（core/session/src/index.ts:668,734），closer 进内存后 91853 已被占据，纯回卷写不出同号 —— 必须先丢弃 closer 才能落回 91853（argszero 在评论区的提示与契约一致）。
3. 关键：当前 master 的写路径 persistContiguous 在落盘前先 assertContiguous（session-persistence/src/storage-contract.ts:145-150），回卷批次在写侧即被拒 —— 该防护 0.1.3-alpha.1 起才存在，你用的 0.1.2-rc.1 早于它，所以旧版漏洞真实。

下一步：请你在最新版上按原复现重试；若仍复现，按 argszero 提示优先排查「第二个进程持锁打开」分支。修复建议 1（截断 + 重放合并为单步原子提交）方向有效；建议 3 的「优先保留后写行」在同形不同因场景会挑错行，慎用。