会话日志在回合中断后因已提交 seq 回退而整条不可加载

[goatliamia]

中断-恢复后，turn/end 先提交了 seq，同一回合的流式输出仍按旧 seq 继续写入，读取器 fail-closed 拒载——一次错误的中间关闭帧让整条会话历史不可用。

复现、预期与验收

• 复现步骤：

  1. 长会话（数十万事件）运行中经历中断-恢复（服务重启、浏览器断连、或上下文压缩 checkpoint）
  2. 之后打开该会话的历史

• 实际结果：
  历史加载失败：history unavailable ... Error: corrupt session log: seq gap in committed region at line 51854 (expected 587030, got 587028)。
  本机两次独立会话的同类损坏（脱敏后相邻事件序列，seq+type）：

  会话 A：
  ... assistant/chunk#215756 , step/end#215757 , turn/end#215758 , assistant/chunk#215757 , assistant/chunk#215758 , ...
  会话 B：
  ... turn/end#587029 , assistant/chunk#587028 , ...（读取时报 expected 587030, got 587028）
  

  形态：终止逻辑先写 step/end+turn/end（把 seq 提交推高），同一回合的流式 chunk 随后仍从被提交过的 seq 继续写——「中间错误关闭帧」。读取器只容忍末尾 torn frame，无法恢复中间的已提交回退，于是整条历史不可用（fail-closed）。删除该错误帧后，用 DSH 自身解码逻辑全量重扫验证 681858 条事件 seq 完全连续（本机已验证，原始文件已备份）。

• 预期结果：

  1. 写入/终止串行化：turn/end 的提交与流式输出互斥，任何中断-恢复都不能产生已提交 seq 回退；或
  2. 读取器把「已结束回合之后又出现的同回合后续事件」视为可恢复的无效记录（丢弃该错误帧、只损失当前回合），而不是让整条会话失效。

• 环境：
  DSH 0.1.1-rc.2，Windows 11，web profile（多插件）；损坏发生在长会话的中断-恢复窗口（无 host 崩溃，重启/断连/压缩即可触发）。

• 验收条件：
  任意中断-恢复后历史仍可加载（或最多只损失损坏回合，不损失整条历史）。

[173787247]

你的判断对：这是 写入竞态，不是文件偶然损坏。

turn/end（以及它前面的 step/end）一旦写入，读取器就把该 seq 当成已提交。中断-恢复时同一回合的流式 assistant/chunk 仍按旧 seq 续写，就会在已提交区间里出现回退。读取器只容忍文件末尾的 torn frame，中间这种帧会 fail-closed，整条历史不可用——和 expected 587030, got 587028、以及你两条会话里 turn/end 后面又出现更小 seq 的 chunk，是对得上的。

已经坏掉的日志（你这条路径是对的）

1. 先复制一份再改。
2. 定位「turn/end 之后、seq 变小或重复的 assistant/chunk」（你标的那一帧）。
3. 删掉从这次错误关闭到该回合残留 chunk 为止的区间，不要从头截断。
4. 用同一套解码逻辑全量重扫，确认 committed 区间 seq 连续后再用 UI 打开。

最多损失当前被打断的那一回合；整条会话不该陪葬。你删帧后 681858 条连续，说明后面数据是好的。

产品上

只修读取器（把「已 turn/end 之后的同回合事件」当无效记录丢掉）就能让历史可开，也满足你的验收。根上仍应让 turn 收尾和流式写出串行，否则中断-恢复还会再写出同样的中间关闭帧。两处都值得做；读取器宽容能先保住长会话。

DSH 0.1.1-rc.2 + web、长会话 + 重启/断连/压缩，足以作为复现条件。

[liyangbing]

这个问题本质上是“持久化游标”和“实时 chunk”混用了同一个序列空间。一个可行的契约是：

• durable event 才分配单调递增的 session seq；
• live streaming chunk 使用独立的 transient cursor（或 seq=0），不能推进 replay cursor；
• turn/end 与流式输出要在同一 session writer/transaction 上串行化；
• 恢复时先校验 durable seq 连续性，再处理未完成 turn/tool call；只对尾部 torn frame 做有限修复，不要静默吞掉中间已提交数据；
• 返回给客户端的恢复状态应区分 replayed、truncated、corrupt 和 needs_action，让用户知道是否需要重跑当前回合。

SandBase Harness 的事件设计采用 append-only durable event log，并将实时消息 chunk 与持久化 replay cursor 分开；其架构文档明确说明 transient live chunks 不推进 replay cursor，crash recovery 还会为 orphaned tool call 注入 placeholder result。事件序列设计、恢复测试。

这不是对当前 DSH 读取器的替代实现；建议把“中断后最多损失当前 turn”作为验收，而不是让整条历史 fail-closed。

[argszero]

从源码侧把「写入竞态」再钉一层：这个形态比「turn/end 与流式串行化」更具体，而且直接改变修复方向。

写入端：同一实例不可能产生 seq 回退

• seq 在 append 时铸成 seq: this.log.length（packages/core/session/src/index.ts:627），同实例内严格单调；append 还有重入守卫（同文件 entry.appending）。
• 落盘走 write-behind 按 FIFO 批量写（packages/session/session-persistence/src/write-behind.ts:140-146，pending.splice(0)，失败原序放回 pending）。

结论：单实例内 turn/end 与流式 chunk 的写出顺序天然串行，验收条件 1（「写入/终止串行化」）在单实例里已经成立，所以它修不掉这个 bug。

回退必然来自第二个「陈旧」写入者

用你贴的序列对一遍：读取报 expected 587030, got 587028，说明 turn/end#587029 在位置 587029 被正常消费——写它的那个 writer，log 是 0..587029；而 chunk#587028 的 writer，log 只有 0..587027（缺了 587028 这一个事件），它的 seq 是对更短前缀铸的。也就是说存在第二个 writer：它读到/持有的是旧前缀（缺了已被前一 writer flush 的 587028），随后它的 append 落在 turn/end 已提交之后，文件里就出现「turn/end#587029 → chunk#587028」的回退序。

候选入口：prepared session cache（DEFAULT_PREPARED_SESSION_CACHE_SIZE=5）或 borrow/load 在 live session 尚未 quiescent（write-behind 200ms 批窗内）时构造的新实例。coordinator 的 load/borrow 先查 ctx.sessions（coordinator.ts:779-786 / 850-856），无 live 才读盘——窗口集中在「会话处置/退休与写后队列清空之间」的时序。修复根在 writer 所有权/静止点：新 writer 激活前必须等旧 writer 的 write-behind drain（write-behind.ts:59 的 drainBarrier 是现成 quiescent 原语），或读前缀时对非 quiescent 状态拒绝激活；单纯「turn/end 与流式互斥」无效，因为单实例里它们本来就互斥。

读取端：fail-closed 的精确触发条件

• 读取器在 seq 失配处只记录 issue、回滚该行（format.ts:386-417），throw 只发生在之后某行含 turn/end 时（:409-411 / :415）。
• 若损坏残区在真正文件末尾、之后没有 turn/end 行，finish() 不抛（:367-374），readPrefix 只按 committedBytes < byteLength 打 tornMarker（index.ts:332-339）→ 变成静默截断（丢弃 gap 之后所有事件，不报错）。你的两条会话都因坏帧后面还有 turn/end 才 fail-closed；若残区正好在尾，用户会得到「少一截但能打开」的日志——这条静默路径值得单独开个 issue。
• 修复建议 2（读取器把已 turn/end 之后的同回合事件当无效丢弃）方向正确，且实现点明确：consumeEventLine 里 seq 失配时按「该行是否位于已提交 turn/end 之后、且类型为 assistant/chunk 等可恢复类型」判定丢弃而非置 issue。

归类：与 #4274（同进程双实例游标分歧）同一机制类——本次是「陈旧第二 writer 与写后批窗竞态」的新实例，表现形态从重复 seq 变为已提交 seq 回退。

[PerryLink]

?"seq ????????????"?????????(?? dsh-permission-rules ????,???????):

# ???????,???/??(frame-preserving zstd ??)
node node_modules/dsh-permission-rules/scripts/repair-session-logs.mjs scan <????>
node node_modules/dsh-permission-rules/scripts/repair-session-logs.mjs repair <????>
# 0.1.2-alpha ?????????????:
node node_modules/dsh-permission-rules/scripts/repair-session-logs.mjs strip <????>

????:scan ????(??????)?repair ???????? ignorable: true?strip ??????????????????? argszero ??????,?????????"???????"?????????:??????????;??????,???????????

[argszero]

PerryLink 的修复脚本我拉下来核对了（dsh-permission-rules@0.6.1 的 scripts/repair-session-logs.mjs, 332 行, frame-preserving zstd 逐帧重写 + 备份）：这个工具修的是未知事件类型这一族（#4811/#5059 线——permissionRules/decision、autoReview/* 等 out-of-repo 审计行在 ignorable 标记出现前被无标记追加, 新 build 读取端 SessionFormatUnsupportedError 拒载; 修复 = 给目标行加 ignorable: true, 其余字节不动, 逐帧解压→过滤→重压, 帧边界存活）。scan/repair 的实现与读取端拒绝链对得上（KNOWN_SESSION_EVENT_TYPES + envelope 的 ignorable 判别）。

需要澄清的一点：它不修本线程的 seq 回退形态。0.6.1 发布版里没有 strip 命令, 也没有任何 seq/truncate/rollback 逻辑。本线程的损坏是「已提交 turn/end 之后出现更小 seq 的 assistant/chunk」（中间帧回退, committed-region gap）——不涉及未知类型行, 加 ignorable: true 救不了它, 因为读取端按 event.seq !== events.length 判 corrupt（format.ts:386-417）, 与行是否 ignorable 无关。这是同一「日志打不开」家族里的两个不同失败模式, 修复策略也正交：未知类型 = 标记可忽略即可读; seq 回退 = 需丢弃/截断违规区间或按规则重排。

不过你的 frame-preserving 重写机制（scanZstdFrames + 逐帧重压）正是做后者最合适的底座：如果给 repair 加一个「低于某 seq watermark 的行丢弃」模式（或直接实现我上条说的读取端丢弃规则——turn/end 之后同回合的 chunk 视为可恢复无效记录）, 就能覆盖 #5103 形态, 顺手补上「静默截断」缺口（残区在文件尾时读取端只打 tornMarker 不报错, 离线工具可以显式报告「截断了 N 行」）。两个修复都值得, 各自对应家族里不同的成员——建议帖子里标注清楚适用范围, 免得后续读者把「标记 ignorable」当成 seq 回退的解法。

[xiaoshenming]

这是同一家族：已提交 turn/end 之后又出现更小 seq 的 chunk，官方 committed 区整段拒读。离线侧 dsh-session-surgeon 可以先 inspect。

• 崩溃恢复闭包撞上还活着的写者：丢掉闭包、保住后面真内容。
• 否则裁到缺口前最后一个完整 turn/end（最多牺牲当前被打断的回合），不会给中间补 seq。
• 不要整文件单帧重压；--apply 先 .bak.<utc>。

dsh plugin --profile web add "github:xiaoshenming/dsh-session-surgeon#main"

根因仍是第二个陈旧写者（desktop/web 双开，或 resume 时 write-behind 还没 drain）。修文件挡不住下一次双写。