Session 创建被静默吞掉：宿主已建会话但 UI 无任何反馈（ui-workspace 0.2.1-rc.2）

[sherlockslf]

Summary

DSH 桌面版 0.2.1-rc.2：点「+」新建对话后界面毫无反应（没有新行、没有报错提示），但宿主其实已经把会话建出来了 —— 磁盘上多出一个只有 boot 事件的空白壳（约 515 B、零 turn/start），要重启 DSH 才看得到；反复点击会累积几十个孤儿会话。

English: In DSH Desktop 0.2.1-rc.2 (ui-workspace 0.2.1-rc.2) a new conversation can be created successfully on the Host while the UI shows nothing at all (no row, no error), and the session only becomes visible after restarting DSH. Repeated clicks accumulate dozens of orphaned blank sessions.

Environment

• DSH Desktop @deepseek-ai/dsh-desktop / @deepseek-ai/dsh-desktop-runtime 0.2.1-rc.2，Windows 11，内置 Node 24.x
• @deepseek-ai/dsh-client-ui-workspace 0.2.1-rc.2、@deepseek-ai/dsh-api-session-controller 0.2.1-rc.2
• 会话存储：<DSH_HOME>/data/sessions/<cwd-bucket>/<session-dir>/session.v4.jsonl.zstd；工作区登记：<DSH_HOME>/data/storages/workspace.json
• 下列行号取自随包发布的 bundle node_modules/@deepseek-ai/dsh-client-ui-workspace/lib/client.js（源码目录 packages/client/ui-workspace）与 node_modules/@deepseek-ai/dsh-api-session-controller/lib/client.js（源码目录 packages/client/api-session-controller）。

Reproduction

1. 打开一个工作区（该工作区在会话库里已存在一个空白会话）。
2. 连续快速点击侧栏工作区分组的「+」（或走工作区选择器 WorkspacePickFlow），或点「+」后立刻切换工作区 / 让插件再发起一次导航。
3. 现象：没有新行、没有任何提示，偶有短暂卡顿。
4. 检查 <DSH_HOME>/data/sessions/...：出现一个或多个约 515 B、只有 boot 事件的会话；它们在 UI 里一直不可见，直到重启 DSH。

Current behavior

• 上述会话已在宿主侧成功创建（出现在 workspace.json 的 sessionIds 中，宿主也推送了 api-session/added），即 session.create 返回成功。
• 但界面既不显示该会话，也没有任何失败提示（详见下方 4 处锚点）。
• 实测证据：2026-10-22T12:26:00Z–12:32:04Z 之间一次性出现 35 个空白壳，其中许多在同一毫秒内出现 9–20 个（多数 cwd = D:\项目开发\dyson_sphere_program）；另测得两批激活阶梯：+0.055s → +6.4 → +12.8 → +19.6 → +26.9 → +35.2 → +44.9 → +54.8 → +64.4s 与 +32s → +233s（约 7–10 s/个）。清理前累计 47 个孤儿壳。

Expected behavior

• 会话创建成功后，界面必须显示它（选中新会话，或至少出现一行可见占位），不能因为一次导航被 abort 就把它丢掉。
• 创建失败必须有用户可见的提示，而不是只写 console.warn。
• 侧栏「+」在已有空白会话时应复用（与 createInWorkspace 一致），不应每次点击都新铸一个。

分析：同一创建链路上的 4 处问题

① 创建成功后若导航已被 abort，会话被静默丢弃 —— openWorkspaceSession L1476-1490：

const navigation = AbortSignal.any([this.ctx.layout.beginNavigation(), this.lifetime.signal]);
let sessionId; → try { sessionId = await this.connectBlank(workspaceId, reuse); } catch { ... }
if (navigation.aborted) return; // L1488：宿主此时已经建好会话
this.replaceMain(sessionId, navigation, "reveal", beforeOpen);

beginNavigation() 会 abort 上一次导航，因此 create 在途时任何第二次导航（再点一次「+」、切工作区、插件调用 openSession/startSession）都会让刚建好的会话彻底不可达：不选中、不提示、也进不了客户端列表。会话在宿主侧存在，所以只有重启才看得见 —— 与「点一下没反应、重启后却多出一堆空对话」完全吻合。

② 创建失败对用户完全不可见 —— startSession L1519-1527 结尾：

.catch((reason) => { console.warn("new session failed:", reason); });

三个入口全是用户动作：L3233-3238 ProjectRowItem.onCreate（侧栏「+」）、L3936-3939 WorkspacePickFlow.onPick、L5181-5184 browserInjected().startSession（对所有客户端插件开放）。

③ 侧栏「+」永不复用空白会话 —— connectBlank L1403-1417：

if (reuse === void 0) return this.sessions.create({ workspaceId }); // L1406

「+」走 startSession(group.workspaceId) 不带 reuse，所以每次点击都新铸会话（对比 L1409 createInWorkspace 会复用已有空白）。与 ①②叠加，几次点击就能攒出几十个壳。

④ 活动连接期间没有任何全量列表刷新 —— api-session-controller/lib/client.js：refreshList() L3246，全 bundle 只有 2 个调用点 —— handleConnected() L3574（连接代际变化）与对外方法 L3906-3908 refresh()；没有任何 UI 调用者。列表因此完全依赖 api-session/added 推送 + 本地乐观 mutation，一旦这条链漏掉，就只能靠重连/重启。相关可见性规则：L958-996 sessionVisible 只显示「当前」的空白会话（L966 if (session.blank && session.id !== current) return false;），所以孤儿空白壳天然不可见。

建议修法

1. 不要因 abort 丢掉结果：保留已创建的 sessionId，被等价导航取代时应选中它，或至少给出可见提示 / 占位行，而不是 return。
2. startSession 的失败要报到 UI（notify({kind:"createFailed"}) 已存在，但只有 openWorkspaceSession 会在 abort 之外走到它）。
3. 侧栏「+」走复用路径（createInWorkspace / reuse 语义），重复点击复用空白会话而不是每次新铸。
4. session.create 往返结束（或 attach 完成）后与列表做一次对账/刷新，而不是只依赖代际刷新的推送事件。

Impact

会话在磁盘上静默泄漏、界面与宿主状态不一致，用户唯一能做的就是重启；而重启又把那一堆孤儿空白会话重新暴露出来。

[liukjx]

补两份独立数据，支持「宿主已建、UI 无反馈」的结论，并补上「为什么会越来越慢」这一段。

1) 同一毫秒多个会话，我这边也抓到了：2026-10-30 00:29:27–00:29:34（Windows Modern Standby 唤醒后 61 秒），7 秒内建了 5 个会话，其中 3 个 createdAt 全是 1793291374606；4 个永久停在 317–321 B header-only；从 00:29:27 到 00:35:09 重启之间无任何响应。

2) activation ladder 的成因：慢的不是磁盘（219 个会话头 328 ms、projcache 4.6 MB / 52–58 ms、58,855 文件目录 1.16 s），而是进程内累积：

• 每个被打开过的会话都会 follow→promote（dsh-api-session-controller/lib/index.js:1510,1586-1593）成常驻 live Agent；RPC 面（typert.host.js:1426-1955）没有 session/close，teardown 只绑在宿主根 ctx（dsh-agent-loop:1749），所以宿主活着就不回收；
• 每个 Agent 各挂一套 skill-filesystem：watchFile(interval:100) + chokidar（dsh-skill-filesystem:26,36-41,341-348,370-383），watchMaxProjects=128 对单 workspace 永不淘汰；
• 每次新建都会全量重扫技能目录，且 collect 缓存 key 含 scopeChain（dsh-skill:270,299）⇒ 新会话必然 miss；
• cordis 全局单表 dispatch 是 O(存活会话数)（cordis:230,258-264），renderer 列表快照是全量重建（ui-workspace/client.js:3585-3618）。

这正好解释你们那两段阶梯（+0.055 s → +64.4 s 与 +32 s → +233 s）：已打开会话越多，每一步越慢。配合 ui-workspace/client.js:1476-1490 里 if (navigation.aborted) return 的丢导航，就会在慢链路上不断累积孤儿壳。

完整分析与用户侧缓解写在 #11479，欢迎补充/反驳。