[Bug] 同一 workspace 多开 dsh 实例导致会话日志 seq 重复损坏:历史会话 seq gap 打不开,且单帧重写可致整个 web 启动崩溃

[MitterMeierGithub]

环境

• dsh CLI / @deepseek-ai/dsh-session-persistence-jsonl:0.1.1-rc.2
• OS:Windows 10,web profile

现象

1. 历史会话打开失败:
   corrupt session log: seq gap in committed region at line 8043 (expected 30152, got 30151)
   另一会话:line 1415 (expected 72302, got 72298)——实际是 seq 72298~72302 五个事件整批重复,不是缺一个。
2. 其中一个会话被(修复用途的)工具整体重写为单帧 zstd 后,dsh web 启动即崩:
   corrupt Zstandard session log: first frame is not exactly one header line
   该会话属于当前 workspace,启动必读,故直接崩溃。

复现路径(观察推断)

同一 workspace 同时运行多个 dsh 实例(web + 终端里的 dsh-tui/headless 修复会话),各自从相同 seq 追加事件 → 日志出现重复 seq。期间任何工具若把整个文件重写为单帧,web 启动即崩。

根因分析(已对照源码)

• dsh-session-persistence-jsonl/lib/index.js 写路径 open(path, "a") 裸追加,无跨进程写锁;
• appendLines 注释(第 1196-1199 行)自述:"leaving partial bytes would create duplicate sequence numbers"——重复 seq 是已知失败模式;
• 格式约定:header 独立一帧(必须单行)+ 事件每批一帧;assertZstdHeaderFrame(第 741-743 行)拒绝"首帧非单行",因此单帧整体压缩必崩。

期望行为

• 同一会话日志应有跨进程写保护(锁/单写者),或崩溃重试时按 seq 去重;
• 已崩溃/重复场景建议可自动修复:读取端已对 torn-tail 有恢复逻辑,但对"已提交区间的重复 seq"无处理。

已完成的本地修复(供参考)

解码全部帧 → 删除 seq <= prev 的重复行 → 校验无重复 → 按 header 一帧 + 事件分批帧重编码 → 原子替换。两个会话均成功恢复打开。

相关问题

• [Bug] Cold history loading fully materializes large/corrupt logs and can stall the entire Web server #1550(Cold history loading fully materializes large/corrupt logs...)
• [BUG] 会话日志中一条 tool/result 引用了不存在的 call id，导致该会话所有请求被供应商 400 拒绝，永久不可用 #1593(会话日志损坏导致会话永久不可用)

[xiaoshenming]

seq 重复损坏我们能修；另外你提到的「整文件压成单帧 zstd → 首帧不是单独一行 header → web 启动即崩」，这是 header-frame-corrupt，官方必读当前 workspace 就会挂。

dsh-session-surgeon 重写时保持 header 单独一帧 + 事件分批帧，apply 前写 .bak.<utc>。seq 重叠按官方语义丢掉 replay 尾巴 / 裁到最后一个完整 turn/end，不发明中间 seq。

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

如果已经单帧写坏、header 解不出来，工具会 refuse（避免越修越坏），这时用备份或把该会话目录先移出 ~/.dsh/sessions 让 web 能起来。

[MedicineKing]

同簇问题（同 #1497：seq 重叠/回退导致 committed 区拒读）。两条不丢历史的解法（官方未打补丁 0.1.1-rc.2 实测：931,455 事件零 seq gap，Session.fromRestore 通过）：

1. 读端容错补丁：SessionLogScanner 遇到已消费过的旧 seq（回退/重复/重叠段）时改为跳过而不是整体拒读——磁盘上的所有已提交内容零裁切保留。你提醒的单帧重写教训我们踩中过并已修正：写回=官方帧结构（header 单独一帧 + checksum），assertZstdHeaderFrame 通过后才算数。
2. 零安装 CLI（dsh-corrupt-session-repair）：node dsh-corrupt-session-repair.mjs 扫描（只读）→ fix 预览 → fix --apply（先写 .bak.zstd；写回与官方同款 checksum 帧——header 单独一帧，assertZstdHeaderFrame 直接接受）。真跳号/物理损坏只报告、绝不重写。

已坏在磁盘上就用 2；想让未来崩溃也看不见就上 1。

[MitterMeierGithub]

读端容错我理解会更有效， 还遇到过在对话目录下有错误的对话session, 然后导致所有读session 崩溃的情况。 而实际上只需要跳过这个错误session 就好了 ---- 回复的原邮件 ---- | 发件人 | ***@***.***> | | 发送日期 | 2026年08月29日 01:01 | | 收件人 | deepseek-ai/deepseek-harness ***@***.***> | | 抄送人 | MitterMeierGithub ***@***.***>, Author ***@***.***> | | 主题 | Re: [deepseek-ai/deepseek-harness] [Bug] 同一 workspace 多开 dsh 实例导致会话日志 seq 重复损坏:历史会话 seq gap 打不开,且单帧重写可致整个 web 启动崩溃 (Discussion #4127) | 同簇问题（同 #1497：seq 重叠/回退导致 committed 区拒读）。两条不丢历史的解法（官方未打补丁 0.1.1-rc.2 实测：931,455 事件零 seq gap，Session.fromRestore 通过）： 读端容错补丁：SessionLogScanner 遇到已消费过的旧 seq（回退/重复/重叠段）时改为跳过而不是整体拒读——磁盘上的所有已提交内容零裁切保留。你提醒的单帧重写教训我们踩中过并已修正：写回=官方帧结构（header 单独一帧 + checksum），assertZstdHeaderFrame 通过后才算数。 零安装 CLI（dsh-corrupt-session-repair）：node dsh-corrupt-session-repair.mjs 扫描（只读）→ fix 预览 → fix --apply（先写 .bak.zstd；写回与官方同款 checksum 帧——header 单独一帧，assertZstdHeaderFrame 直接接受）。真跳号/物理损坏只报告、绝不重写。 已坏在磁盘上就用 2；想让未来崩溃也看不见就上 1。 — Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today! You are receiving this because you authored the thread.Message ID: ***@***.***>

[MedicineKing]

同意——单个会话损坏不应该拖垮整个 workspace 的启动。这其实是两层问题：

1. seq 层拒读（你遇到的 seq 重复/重叠导致 corrupt session log）：读端容错补丁方向处理（scanner 对已消费过的旧 seq 跳过而非整体拒读）。
2. loader 级 fault isolation（你说的"跳过这个错误 session"）：单个会话 header/帧损坏（比如单帧写坏的 header-frame-corrupt）不应让 web 启动读全部会话时直接崩溃——这是你建议的价值点，也是目前读端"拒读单个坏文件"的强默认行为之外的值得讨论的宽容度。

我们此前只在"读端容错"层面做过工作（seq 层）；你提的隔离层（bad session 跳过而非全局崩溃）值得列入正式议题——如果官方接受"跳过+告警+备份提示"作为默认行为，那个"坏文件拖垮全部"的崩溃族就整体降级为个案。我们把这件事记入待办（待官方分支审计时一并提出）。