归档会话在界面中不可找回, 且分叉会话失败无提示

[Viowater]

问题描述

版本: v0.1.0-rc.5

1. 左侧会话栏点某会话行的「…」→「归档会话」: 该行立刻从所有视图消失, 界面中没有任何「已归档」分组或「取消归档」入口, 这个不知道是设计如此还是bug, 但我用起来感觉好怪, 而且万一误触了也没法找回, 社区也在反映这点. 所以我比较倾向是bug。检查 ~/.dsh/storages/workspace.json 确认会话 id 进入了 archivedSessionIds, 会话日志完好——数据没有丢, 但用户无法找回。
   2.左侧会话栏点某会话行的「…」→「分叉会话」: 会话会直接消失. 应该是出于某种原因, 主机返回了 fork-unavailable, 而客户端把错误静默吞掉(forkSession 的 .catch(() => {})), 用户得不到任何反馈, 也不知道没成功。

复现步骤

1. 打开 Web GUI(左侧会话栏), 对任意有已完成轮的会话点「…」→「归档会话」→ 观察该行消失且无任何找回入口。
2. 新建一个会话、发出提问后立即(在该轮完成前)点「…」→「分叉会话」→ 观察界面无任何提示。(有时候对于已有几轮的会话, 会导致会话消失)

实际结果: 归档的会话从界面彻底消失, 无恢复途径; 分叉失败无提示, 从左侧会话栏点击分叉可能导致会话消失。
预期结果: 归档后仍能在「已归档」分组中看到并「取消归档」恢复原位; 分叉失败弹出错误说明, 从左侧会话栏点击分叉不会导致会话消失.

根因与解决方案(供参考)

• 根因 1: 归档是单向的——客户端 tree.ts 的 sessionVisible 排除 archivedSessionIds, 而产品没有 unarchive RPC/入口(工作区 registry 保留 sessionIds 槽位正是为将来取消归档恢复位置)。
• 根因 2: ui-workspace 的 forkSession 对失败 .catch(() => {}) 静默吞掉。

[argszero]

两个问题的根因你都定位对了，我在当前 master（47f943859b）上逐一复核，补充设计意图与修复方向。

Bug 1：归档单向（#1587 家族，设计缺口 + UX 事故）

• 客户端 tree.ts:118 的 sessionVisible() 把归档会话排除出所有视图（:188/:199 两处列表构建都过它）——所以"从界面彻底消失"不是幻觉，是过滤器直接砍掉的。
• 这不是新引入的 bug，而是一个文档化的设计缺口：工作区 registry 的 archivedSessionIds 是全局集合（workspace/src/index.ts:230-238,244-259），且 unarchive 全仓根本不存在——只有 :102 的 JSDoc 承诺（"sessionIds 槽位正是为将来取消归档恢复位置"）。也就是说设计上预留了取消归档的位置，但功能从未落地。
• 社区已多次撞上：#1666（归档后任务仍在跑，无可见状态）、#1853（本次）。你检查的 workspace.json 里 archivedSessionIds 正确、会话日志完好——数据零丢失，但用户层不可达，误触即"永久隐藏"。这个 UX 后果把它从"设计如此"推成了"实际 bug"。
• 修复方向（PR 蓝图已就绪，上游通道开放即可提交）：① host 加 unarchiveSession RPC（registry 反向操作，sessionIds 槽位归位）；② 客户端树加「已归档」分组 + 每行「取消归档」入口；③ 归档时若该会话正在运行，明确提示"归档≠停止"（与 Bug: Archived active conversation keeps running with no visible status #1666 联动）。

Bug 2：分叉失败静默吞掉（独立客户端 bug，新发现）

• ui-workspace/src/client/index.ts:85-91 的 forkSession 确实是 .catch(() => {}) 静默吞掉（:88-90，注释"Fork or child-rename failure keeps the current selection"——设计意图是保持选中，但零用户反馈）。
• 主机侧 fork-unavailable 是真实存在的错误码（api-proxy.ts:2392）：当 atSeq 锚定的回合尚未 turn/end（sessions.ts:329 "An in-log anchor whose turn is still open fails with fork-unavailable"）、或会话没有任何已完成回合时返回。你复现的"新建会话、发出提问后立即分叉"正好命中后者——首轮还在进行中，无已完成边界可叉 → 主机拒绝 → 客户端吞掉 → 用户以为点了没反应。
• 修复方向：① 客户端把 fork 错误（至少 fork-unavailable）以 toast/notice 呈现，附原因（"该回合尚未完成"）；② 产品层面可考虑：无已完成回合时给"等待回合完成后再分叉"的引导，而非静默失败；③ "分叉导致会话消失"——这个现象我未能从源码确认（forkSession.then 只 open(childId)，理论上是打开子会话而非隐藏父会话），如果你有稳定复现（哪个入口、会话有几轮、分叉前状态），可以单独开一帖带 JSONL 跟进——可能与"打开子会话时当前会话切换"的树状态刷新有关。

家族连接：Bug 1 属于我追踪的归档/工作区家族（#1587 单向归档 + #1666 归档后运行无状态）；Bug 2 是客户端错误处理家族的新成员（与 #1607 工具超时无反馈、#1615 状态判定等"静默失败/状态不可见"同类）。两个都值得修，且都是小改动。