[Bug] 桌面端升级迁移会把已禁用的可选 bundle 重新启用并与依赖安装竞态，首启 sessionController 不可用、无法新建会话

[mjdndd]

• 版本：Desktop 0.2.2-rc.2 → 0.2.2-rc.3（Windows 11，profile desktop）
• 涉及包：@deepseek-ai/dsh-experimental-terminal-bundle、@deepseek-ai/dsh-experimental-session-search
• 相关文档：v0.2.1-rc.2 persistent-terminal-controls（"从 dsh.profile.bundles 移除即禁用"）

摘要

升级前我按文档把两个可选 bundle 从 dsh.profile.bundles 移除（禁用）。升级到 rc.3 后：

1. 它们被升级迁移自动重新写回 dsh.profile.bundles 并升到 rc.3 —— 用户的禁用选择被覆盖；
2. 迁移的 pnpm 安装（14:01:09–14:01:22）与首次启动发生在同一分钟内，首启报
   gateway/service-unavailable: typert gateway: session/create: active Service "sessionController" is unavailable，
   无法新建任何会话；
3. 完全退出应用再启动一次后，所有行（含两个可选 bundle、session-controller）均为 active，恢复正常。

同一签名上一次也出现过（2026-11-12，rc.1 → rc.2，当时是 rc.1 的 bundle 在 rc.2 上加载失败）。这次即使先禁用也没能避免，因为迁移把禁用状态还原了。

复现步骤

1. 在 ~/.dsh/profiles/desktop/package.json 中把两个可选 bundle 从 dsh.profile.bundles 移除（或在插件页关闭），确认文件里已无这两项；
2. 通过应用内更新从 rc.2 升级到 rc.3；
3. 首次启动后尝试「新建会话」。

期望

1. 升级迁移不应重新启用用户显式移除的 bundle（dsh.profile.bundles 是文档定义的开关，见上方 guide）；
2. 任何可选 bundle 加载失败都不应导致 sessionController 不可用——宿主应降级启动、指出失败的具体 bundle，并允许“安全模式”进入。

实际

• 首启截图错误：新建会话失败: gateway/service-unavailable: typert gateway: session/create: active Service "sessionController" is unavailable
• UI 没有给出“哪个插件失败”的任何线索，用户只能靠猜/找第三方工具救场。

证据（时间线，本机）

时间	事件
13:52:41	禁用后写回 package.json：bundles = [dsh-base, dsh-web-app, dshmarket, @dsh-pet/bridge]，deps 仍为 rc.2
14:00:52	应用升级迁移创建备份目录 .backup-20261115-140052，其中 package.json 确认不含两个可选 bundle
14:01:09	package.json 被重写：bundles 中重新出现两个可选 bundle，deps 变为 0.2.2-rc.3
14:01:22	node_modules/.pnpm-workspace-state-v1.json 校验时间戳（pnpm install 完成）
首启	上述 sessionController 错误，无法新建会话
完全退出后重启	list_plugins：session-controller、optional-terminal-*、optional-session-query-* 全部 active

补充：dsh.profile.bundles 的禁用状态没有任何持久标记，迁移无法区分“从未启用”和“用户禁用”，这可能是根因；但无论意图如何，把禁用项静默恢复都违背了文档里“移除即禁用”的约定。

影响

• 用户侧：升级后整个 Web UI 不可用（不能新建/恢复会话），且错误信息指向内部服务名，普通用户无法自救；
• 与可选/实验 bundle 的版本升级叠加时（本次正是如此），问题会稳定复现于“升级后首启”这个窗口。

建议修复

1. 迁移时保留 dsh.profile.bundles 中的用户选择：只升级 dependencies 里已存在的版本，不把移除过的条目加回；
2. 或在 profile 中记录显式的 disabledBundles，让“禁用”跨升级持久化；
3. 可选 bundle 加载失败隔离：不要把 session-controller 等核心行拖下水，错误里带上失败包的 name@version；
4. 提供“安全模式”/“以禁用可选 bundle 启动”的入口，避免用户只能靠外部工具修复。

环境

• OS：Windows 11
• Desktop：0.2.2-rc.3（安装目录 D:\安装\黑色大肥鱼，更新通道 nightly）
• Profile：desktop（~/.dsh/profiles/desktop）
• 插件状态（修复后）：@deepseek-ai/dsh-base / dsh-web-app 0.2.2-rc.3，两个实验 bundle 0.2.2-rc.3，全部 active

[PerryLink]

两件事可以分开看：bundle 列表被补回，和首启装依赖的竞态。

bundle 列表的自动合并逻辑在 packages/boot/plugin-manager/src/operations.ts:100-125：包操作完成后，会把这次"新出现的依赖"里带 bundle 元数据的名字补进 dsh.profile.bundles（:117-122）；插件页的开关只改列表本身（packages/boot/plugin-manager/src/index.ts:1294-1296）。没有"用户禁用"这个持久标记，所以从列表里移除之后，下一次包操作就可能把它当成待补齐的 bundle 重新写回来。至于升级迁移具体在哪一步写回，我这边没能从树里定到唯一路径，这点标记为推断。

首启 sessionController 不可用是安装和启动的竞态：依赖安装（14:01:22）和第一次挂载在同一分钟，核心 bundle 还没落齐；你第二次启动全部 active，说明加载本身没问题。

临时处置：升级后先完整退出再启动一次；想守住禁用状态，除了从 dsh.profile.bundles 移除，也把对应包从 package.json 的 dependencies 里去掉，这样 reconcile 没有可补回的来源。

这段可以交给 AI，让它按你 profile 里的实际列表核对；如果这条解决了你的问题，可以标成 answer，后面遇到同样问题的人更容易找到。

[dongsheng123132]

macOS / Desktop 0.2.2-rc.3 这边印证了「停用状态不持久」：手动把 7 个第三方 bundle 全部停用（bundles 16 → 9）后重启，host 又把它们全部自动重新启用（bundles 回到 21）。所以靠停用插件自救这条路走不通，也和你的迁移写回观察对得上。

不过想补充一个可能要分开看的点：我这边首启的 sessionController 不可用并不是竞态导致的——完全退出应用再启动一次仍然报错，直到把 profile 里 8 个 0.2.2-rc.2 的官方包整体隔离、把三个显式依赖对齐到 rc.3 之后才恢复。也就是说「升级后首启 sessionController 不可用」这个签名下面至少有两种成因：

• 你这条：升级迁移的 pnpm 安装与首启竞态，再启动一次就好；
• [Bug] 升级后可选插件遮蔽核心包，导致 workspace/session 服务全部不可用，界面表现为"会话全部丢失"（数据实际完好） #13385 / 我这条：旧版官方包被 hoist 到 profile 顶层、被兼容性门禁禁用，storageDomain → workspaceRegistry → sessionController 连锁 pending，重启多少次都不会好，必须对齐版本线。

判据可以是「完全退出后重启是否恢复」：能恢复更像竞态，不能恢复就去看 did not activate 的行数和官方包版本线。可回滚的完整修法在 #13389。

[mjdndd]

补充与更正（原帖作者）：

复盘后发现有两点归因错了，先向维护者致歉，也把真实根因补上。

更正 1：14:01 对 package.json 的改动不是应用迁移做的。
那是本地修复工具（opencode）在 14:00:52 备份后手动改的：把两个实验包从 rc.2 升到 rc.3，并把 bundles 两行加回。所以“迁移把禁用项写回”这个结论不成立（PerryLink 指出的 reconcile 逻辑本身存在，但不是这次的实际路径）。当时看到的 .backup-20261115-140052 也是修复工具建的，不是应用。

更正 2：根因不是安装/启动竞态，而是 profile 内 rc.2 包遮蔽内核包。
node_modules/@deepseek-ai/dsh-session-query-sqlite@0.2.2-rc.2 的 peer 依赖锁死：dsh-session / dsh-session-query / dsh-session-persistence = 0.2.2-rc.2。内核升到 rc.3 后，这个同名包仍从 profile 被解析到，命中兼容性门禁（@deepseek-ai/dsh-app-boot/lib/index.js:1158），row 被禁用，sessionController 级联缺失 → session/create 报 active Service "sessionController" is unavailable。因此完全退出重启并不会恢复（试过），必须把版本线对齐。这与 #13385 / #13389 是同一根因族，dongsheng123132 的判据在我们这里成立。

关键细节：只从 dsh.profile.bundles 移除是不够的。
升级前我们已经把两个 bundle 从 bundles 列表移除，故障依旧——因为 rc.2 包还装在 node_modules 里，照样遮蔽内核。必须同时处理 dependencies（PerryLink 的建议方向是对的），或者让内核在版本不符时忽略 profile 副本。

修复动作（可复现）

1. 退出应用；2. 备份 profile；3. dependencies 两个实验包 rc.2 → rc.3，恢复 bundles 行；4. pnpm install --no-frozen-lockfile（frozen 会报 ERR_PNPM_OUTDATED_LOCKFILE）；5. 重启。之后 list_plugins 里 session-controller / 两个 optional bundle 全部 active。

旁证
.dsh-market/log.ndjson 2026-11-15T05:58:21Z、06:08:31Z：市场尝试把 session-search 升到 rc.3，两次都因 not-removable（桌面端自己管理）失败——版本错配在升级后就已存在，且用户在 UI 里没有自救路径。

建议（与 #13385 合并看）

1. 内核版本 ≠ profile 包版本时，回退使用内核自带包，而不是禁用 row 让 sessionController 级联缺失；错误应直接指出版本错配的包。
2. 市场/插件页提供“同步到当前内核版本”的一键升级（现在 not-removable 让用户既不能升也不能卸）。