# [BUG] 升级 dsh 0.1.5 后，此前手工重编号修复过的会话无法加载（chunk 溯源校验拒绝）

[2522669008-zcy]

背景：这是对[#4178 ]的后续发现。原帖记录了"两个 dsh 实例并发写同一会话导致 seq 冲突"的损坏、恢复与预防；本帖记录升级新版后暴露出的二次问题：当时用于修复的手工重编号，留下了新版会拒绝的内部引用。

现象

把 dsh 从 0.1.1-rc.2 升级到 0.1.5-rc.1 后，此前修复过的会话重新无法打开，服务端报：

failed to observe session "session-fd18fa92-…":
assistant/message 139130 chunk provenance is not one complete ordered attempt;
source v0 artifact remains unchanged

注意最后一句：迁移失败时保留原始 v0 文件不变，不会造成进一步损坏——这点体验很好。

根因

0.1.5 引入了会话格式 v0 → v2 迁移，迁移时校验 assistant/message 的 sourceEventSeqs（chunk 溯源）必须与实际 chunk 序列完全一致（长度相同、逐个 seq 相等）。

而此前为修复"seq 重复/回退"所做的手工修复（把冲突片段重编号）只改了事件的 seq 字段，没有同步事件内部的 sourceEventSeqs 引用。旧版不校验该字段，因此一直正常；新版一旦校验便拒绝加载。

本例中恰好 4 条消息的溯源数组仍是旧编号（长度都对，只是整体偏移）：

消息 seq	轮次	需要的偏移	来源
139130	67	+1	一次"尾部整体 +1"重编号
140110	68	+1	同上
140388	69	+1	同上
163948	88	+867	一次"把冲突片段接到日志尾部"的修复

修复方法

对每条 assistant/message：

1. 从日志重建它所属 attempt（同 turn + step）的实际 chunk seq 序列；
2. 与其 sourceEventSeqs 逐项比较；
3. 若长度一致且偏移均匀，则按该偏移重写数组（非均匀偏移则拒绝修复，避免猜测）。

本次只改动了这 4 个数组，其余 12818 行原样保留。

修复后验证：

• 本地校验：溯源问题 0、seq 全程连续、末 seq 不变（179943）；
• 服务端：session/page 返回 ok: true，可正常读取历史记录；
• 修改前文件已完整备份。

可复现性

可复现：任何"重编号过 seq 但未同步内部引用"的会话，在 0.1.5+ 上都会触发同一错误。错误信息带具体 seq 与事件类型，便于定位。

对修复工具的启示

• 采用"裁切"策略的工具（如 @xiaoshenming 的 dsh-session-surgeon）天然避开该问题：裁切不改变幸存事件的编号；
• 但任何"重编号续接"方案（把冲突片段接到日志尾部）必须同步重映射事件内部的跨引用，至少包括：
  • assistant/message.sourceEventSeqs（本次遇到）
  • 可能存在的 tool/result.sourceEventSeqs
  • compaction 的 shadowedRange
  • surface 替换的 start / end 等范围引用

附：新版接口变化（供工具作者参考）

• Web 端启用了 Cookie 鉴权：直接请求首页也会返回 401，需先访问 dsh web 打印的带 launch token 的 URL；
• 旧接口 session.history 已由 session/page 取代，入参形如
  { request: { address: { kind: "session", sessionId }, throughSeq, maxMessages } }。

[2522669008-zcy]

传送门 · 相关官方讨论（2026-09-11 更新）

本贴记录的是「两个 dsh 实例并发写同一会话」导致的 seq 冲突、恢复与预防。如果你是从升级 dsh 0.1.5 之后会话打不开找过来的，下面这些帖子更新、更对口：

• #6151 升级到 0.1.5 后，以前的一些老会话打不开了 —— 汇总帖，覆盖 0.1.5 转换器会拒绝的几种形态（xiaoshenming 指明"细节在 升级到 0.1.5 后，以前的一些老会话打不开了 #6151"）
• #6175 更新 0.1.5-rc.1 后大部分会话打不开 —— 对应报错 assistant/message … chunk provenance is not one complete ordered attempt，该帖下已有修复工具方案
• #6189 permission/preset 成员形态 ／ #6194 插件来源 form 形态 —— 另外两种拒绝形态

修复工具：dsh-session-surgeon —— main 分支已是 0.2.0，新增 src/migrate.mjs 处理上述 4 种 v0-* 形态（含 chunk 溯源：改为引用磁盘上已有的有序 chunk 段，不发明 seq）。注意目前只有 v0.1.0 打了 tag，要拿到新修复需从 main 安装。

预防（本贴结论，仍然有效）：

• dsh-single-instance-guard：同一 DSH_HOME 下第二个实例启动即被拒绝；
• 测试/实验使用独立数据目录（DSH_HOME=~/.dsh-test），与正式环境零共享。

补充：本贴提到的会话最终也已确认——chunk 溯源问题可按"引用磁盘上已有的有序 chunk 段"修复，修复后 session/page 返回 ok: true，会话恢复正常。

[xiaoshenming]

这块 surgeon 已经自动化，而且不需要"偏移均匀"这个前提。

v0-chunk-provenance 不按偏移量算，而是直接从磁盘重建该消息所属的 attempt：同 (turn, step)、自上一个 turn/end / step/end / llm/retry / llm/retry-started（与官方 v1→v2 closesAttempt 一致）以来的 assistant/chunk 序列，然后把它写进 sourceEventSeqs。所以整段 +1、整段 +867、甚至混合偏移都是同一套处理：只引用磁盘上真实存在的 seq，不发明序号、不删事件。

边界与流程：

• surfaceOp: replace 的消息（/rewind 撤回标记）绝不动 —— 它引用的是 applySurface 要求的 shadowed 节点，不是 chunk run；
• 没有可用 chunk run 时改成空引用，不猜；
• 先停写者 → inspect <id> 看 health → repair --dry-run（会列出每条要改什么）→ --apply（先写 .bak.<utc>，可回滚）。

验证方式和你贴的一致：拿官方 0.1.7-rc.1 的 sessionFormatV0ToV1 stage 对照，修前拒、修后过；seq 全程连续、末 seq 不变。相关 commit：519ea4d（形状本体）、23987e4（重试边界，issue #3）。