v1.16 会话恢复（Recovery）无限循环：每次启动都创建 -recovery- 副本，丢失对话内容

[luohuayouyisuiliushui]

环境信息

• 操作系统: Windows
• 桌面版版本: 1.16
• 使用的 provider: deepseek/deepseek-v4-flash

问题描述

每次启动应用或打开对话时，桌面版都会触发会话恢复机制，形成无限 recovery 循环：

1. 启动时检测到 "stale runtime"（过期运行时）
2. 创建一个 -recovery-{hash} 的新会话文件副本
3. 新副本只保留了第一轮对话（turns: 1），之前的内容全部丢失
4. 下次启动又对 recovery 文件再次执行 recovery → 无限循环

实际证据

在 %APPDATA%\reasonix\projects\<project>\sessions\ 目录下可看到 recovery 链不断增长：

原始:              ...-deepseek-v4-flash.jsonl
第1次 recovery:    ...-recovery-4cbd7414.jsonl
第2次 recovery:    ...-recovery-7b853d8a.jsonl
第3次 recovery:    ...-recovery-a6df07e4.jsonl
第4次 recovery:    ...-recovery-85a714b4.jsonl
第5次 recovery:    ...-recovery-98aef07e.jsonl  ← 当前在用

另一个项目甚至出现了 7 次 recovery 的链。

Meta 文件关键字段

每个 recovery 文件的 .meta 内容：

{
  "name": "Recovered unsaved changes from stale runtime",
  "recovery_reason": "snapshot conflict",
  "topic_title": "恢复分支 · 恢复",
  "turns": 1,
  "recovered": true
}

注意 turns: 1——每次 recovery 只保留了第一条消息，其余对话内容全部丢失。

影响

• 每次对话都弹恢复提示，干扰正常使用
• 旧对话内容不断丢失
• 会话目录积累大量冗余文件
• 显示为 "恢复分支 · 恢复" 的新主题不断出现

根因分析

Recovery 机制在创建恢复副本后，没有正确标记原始会话为"已恢复"状态，导致下次启动时再次对已恢复的文件执行同样的 recovery 操作。

关键判断逻辑疑似在比较 snapshot 时，即使会话已经正常关闭，仍判定为 "snapshot conflict"，从而不断触发恢复。

临时解决方法

每次重新打开应用前手动删除 sessions 目录下多余的 recovery 链文件，只保留最新的会话文件。

期望

1. recovery 机制应只触发一次，恢复完成后标记状态
2. 下次启动不应再次对已恢复的会话执行 recovery
3. 或者提供选项让用户关闭自动恢复功能