[桌面端] 会话日志损坏后不可恢复、也无法再出现在列表中（seq gap / does not match an open turn and step，缺修复与重扫入口）

[weiye2006]

TL;DR

1. 在桌面端运行中把旧的会话日志覆盖回 ~/.dsh/sessions（做备份/恢复时很常见），会让宿主内存里的 seq 领先于磁盘；宿主不校验文件尾，之后继续追加即形成永久 seq 空洞，会话从此无法加载。
2. 日志一旦损坏，整个会话不可用：没有部分加载、没有修复工具、没有 CLI 校验入口，界面只有一行 SessionFormatError。
3. 即使事后把日志修好，会话也不会回到列表：可见性依赖 ~/.dsh/storages/workspace.json 的 sessionIds 登记表，损坏成员被静默跳过，且没有"重新扫描 / 导入会话"入口。

---

环境

• DeepSeek Harness 桌面端 Windows x64，应用与 @deepseek-ai/dsh-session-format 均为 0.2.1-rc.3
• DSH_HOME=C:\Users\<user>\.dsh，profile=desktop
• 会话日志格式：多 zstd 帧拼接，每帧若干 JSONL 行，逐行带全局 seq

---

事故经过

时间	事件
22:07	覆盖重装桌面端（同版本），~/.dsh 被重建为空配置
22:17–22:27	从旧备份恢复 profile / 会话 / 凭证，应用被脚本停止后重启，恢复报告全绿
22:44:47	生成一份快照（应用运行中，日志为逐条 append 的文件）
22:45:55–22:46:02	用该快照恢复 ~/.dsh/sessions，应用未停止
22:46:02 起	宿主内存 seq 已推进到 153，而磁盘被替换成只到 109 的旧副本；下一次追加从 153 开始写
结果	3 个会话各出现 43 / 66 / 60 个事件的连续空洞

加载时报错：

stored session "…" is corrupt: SessionFormatError:
invalid committed event at line 111: released v2 row 110 has seq gap (expected 110, got 153)

把 seq 补平后又暴露第二层（丢失的事件里含 turn/start、step/start，后续事件的 data.turn/step 悬空）：

SessionFormatError: assistant/message does not match an open turn and step

---

问题与建议

1. 运行中的应用对外部改写没有任何检测（最高优先级）

宿主持有内存中的 seq 计数器，追加时不校验文件实际最后一条 seq / 长度 / mtime。外部把文件换掉就会产生空洞，且宿主完全无感。

建议：每次 append 前做一次廉价校验（文件长度 + 最后一条 seq + mtime），不一致时显式收尾并开启新段，而不是静默写出缺口；或对会话日志持有 advisory lock，外部工具必须获取它才能替换。

2. 损坏会话无部分加载 / 无修复能力

当前是全有或全无，对用户等于整段对话丢失。

建议：提供"截断加载"（读到最后一个合法事件）与 dsh session verify / dsh session repair。

本机已验证可行的修复策略：闭合 seq 空洞后重映射 seq / throughSeq / headerSeq / messageSeqs[] / sourceEventSeqs[]；为丢失的 turn/step 起始事件插入最小桥接行；为丢了结果的 tool call 插入标准 interrupted 结果。

3. 会话可见性依赖手工登记表，且没有"重新扫描"入口

storages/workspace.json 的 sessionIds 是权威源（schema 原文 "Sessions accounted to this Workspace in manual order"）。日志损坏的会话在索引时被静默跳过；事后修好也不会自动补登；UI 无导入/重扫入口。

实测：手工把 3 个 sessionId 写回 sessionIds（宿主未回写该文件，mtime 未变），重启后数组仍在，但列表依旧不显示 —— 说明登记只是必要条件，宿主侧仍因加载失败而过滤。

建议：提供 Rescan / Import sessions；对加载失败的会话给可见占位条目 + 失败原因，而不是静默消失。

4. 崩溃诊断信息随重装一起丢失

弹窗给出 %APPDATA%\@deepseek-ai\dsh-desktop\crash-<ts>-host.log，但重装会重建该目录（本次同时重建了 ~/.dsh），日志直接消失，无法定位。

建议：崩溃日志写到稳定目录（如 ~/.dsh/logs/）并保留多份；提供"导出诊断包"；重装不清理。

5. 备份/恢复缺少一致性协议

dsh 没有对外暴露"我要动你的数据"的信号，也没有单实例写锁文件供外部工具协商。

建议：提供 writer.lock 或 dsh stop/lock 协作机制，文档明确"改动 sessions 前必须持有它"。

6. 缺少命令行自检入口

用户无法自行判断"日志是否完整"。一个只读的 dsh session verify --all 就能把这类问题从玄学损坏变成可操作项。

---

最小复现

1. 启动桌面端，打开会话产生若干事件；
2. 外部把该会话的 session.v4.jsonl.zstd 替换为更早副本（少若干 seq），宿主不感知；
3. 继续产生事件 → 文件出现 seq 空洞；
4. 重启并打开该会话 → seq gap 报错，会话不可用且不再出现在列表。

---

本机临时缓解（非官方，供参考）

• 自写 session-check.js：校验单 header、seq 0..N-1 连续、v4 的 turn/step 与工具生命周期；
• 备份脚本在运行中拷贝日志后立即校验，不合格自动重拷（3 次），仍不合格则不发布快照；
• 恢复脚本对"-NoStop + 活动数据目录"无条件拒绝，恢复前校验快照日志、恢复后校验落地日志，失败自动回滚。

---

本反馈不含任何凭证或个人数据；会话内容未上传。

[weiye2006]

dsh-session-session-b6a36860-fae2-4554-b48b-32976978862b.zip
附上会话记录