Desktop 0.2.1-rc.2：更新插件市场会让应用退出、profile 留在“bundles 条目丢失但依赖还在”的半卸载状态

[ltmroberthk915]

Desktop 0.2.1-rc.2：更新插件市场会让应用退出、profile 留在“bundles 条目丢失但依赖还在”的半卸载状态

本仓库 issue 已关闭，按仓库设置改发 Discussions；如果这里不合适，麻烦指个正确的反馈入口。

环境

• DSH Desktop 0.2.1-rc.2（Windows 11 x64，官方安装包，DeepSeek Harness.exe FileVersion 0.2.1-rc.2）
• profile：desktop，patchReload: live（HMR 开启）
• dshmarket@1.66.27（后升级到 1.66.35）、dsh-free-search@0.9.0

现象（可复现两次）

在市场里点“更新市场”（更新 dshmarket 自己）：

1. 市场调用 pluginManager.installBundle("dshmarket@x")；
2. 宿主以 {"code":"already-installed"} 拒绝（HMR 下对已安装包直接 add 会被拒，插件管理器
   README 也写明“装另一个版本需要先卸载再安装”）；
3. 市场的兜底随后调用 pluginManager.removeBundle("dshmarket")；
4. 这一步卸载的正是“正在执行这次请求、正在提供市场 UI 的插件自己”，应用退出/重启；
5. 重启后 package.json 的 dsh.profile.bundles 里 dshmarket 条目消失，但
   dependencies.dshmarket 与 node_modules/dshmarket 都完好（“假卸载”）；
6. 宿主启动时没有对账修复，市场从 UI 上彻底消失；用户只能手改 package.json。

时间点（UTC+8）：

• 2026-10-17 22:54：更新返回 already-installed，rollback 同错；
• 2026-10-17 23:46 前后：点更新市场后市场消失；应用进程 23:46:07 重启，23:46:41 写回缺
  dshmarket 的 package.json；.dsh-market/log.ndjson 与 .plugin-manager/logs 都没有这次操作
  的任何记录（没有新的 operation-*，pnpm 没有跑）。

期望

1. 禁止自移除：removeBundle 不应允许移除“当前正在处理该请求的 bundle”，或至少要求显式确认；
2. 提供原子更新：宿主暴露 updateBundle / restartToApply 之类的接口，调用方不需要
   remove+re-add（现在的组合在“更新自己”时必然出问题）；
3. 写前日志：removeBundle 真正动手前先落一条日志，崩溃时至少能查到“谁要卸谁”；
4. 启动对账：用已安装依赖修复 dsh.profile.bundles，自动恢复“假卸载”半状态；
5. 半状态可见：至少在插件页/市场顶部提示“某 bundle 声明缺失，可一键恢复”，不要让用户手改清单。

证据

• ~/.dsh/profiles/desktop/package.json：dependencies.dshmarket 存在，dsh.profile.bundles 缺条目
• .dsh-market/log.ndjson：22:54 的 already-installed 与 update-rollback 记录
• .plugin-manager/logs/operation-KOq7p0/pnpm.log：更早的一次 remove；本次操作没有对应目录
• 市场侧同问题（含 1.66.35 仍未加自我特判的核对）：
  [Bug][Desktop] 自更新会把 dshmarket 自己卸载掉：removeBundle 后 installBundle 未执行，市场从 profile 消失（1.66.33 / 1.66.34 实证） dsh-market/dsh-market#900

备注

插件市场 1.66.35 的 installOrReinstall() 仍是 removeBundle + 重新安装，没有对“目标是自己”的保护；
我核对过 npm tarball 与本机安装目录。因此这个问题的修复点更适合放在宿主侧（见“期望”1/3/4）。

[ltmroberthk915]

补充一条同一次事故里的宿主侧新现场（比自更新本身更严重：它让所有插件操作都失败）。

现象

2026-10-18 01:53（UTC+8）崩溃重启后，~/.dsh/profiles/desktop/package.json.lock 残留下来：

• 文件内容 = 17512，即当前存活的 dsh-desktop-host 进程自己的 PID（进程创建于 01:53:28）；
• 文件 mtime 01:53:54，package.json 在 01:53:55 被成功写入，但锁没有释放；
• 此后所有需要写 profile 的操作（设置 → 实验性插件 的开关、市场里安装/更新/卸载）都失败，报：

启用失败：atomic-write: timed out waiting for the writer lock at
C:\Users\Ming\.dsh\profiles\desktop\package.json.lock

为什么不会自愈

@deepseek-ai/dsh-atomic-write 的 withFileLock() 在锁冲突时只调用 takeOverExitedLock() ——
它只在记录里的 PID 已退出时才接管。这里 PID 是存活的 host 自己（可能是启动时的写入操作
没有走完 finally），于是每个后来者都只能等到超时；UI 上没有任何“解锁/恢复”入口。

处理

按 atomic-write 注释里的口径（“a live process reused keeps its lock until an operator removes it”），
人工删除该文件后，3 秒内没有新的 writer 重建它，写入立即恢复：

• 删除前：package.json.lock = 17512，mtime 01:53:54；
• 删除后：文件消失、无新锁；profile 写入恢复正常。

建议

1. 异常路径也要释放锁：进程被信号/崩溃打断时，锁文件应可被下一次启动识别并清理；
2. 超时接管：超过一定时长（例如写操作本该秒级完成）后，存活 PID 的锁也应允许接管，或至少提供
   dsh profile unlock 这类显式命令；
3. UI 报错要给出口：现在只显示 atomic-write: timed out...，用户完全不知道要去删哪个文件；
4. 启动时对 package.json.lock 做一次一致性检查（PID 存活但锁龄过久 → 提示或自动清理）。

这条与自更新的关系：自更新/崩溃是触发场景，但“残留锁 + 只认已退出 PID”是宿主侧独立缺陷，
它会让整个插件系统瘫痪，建议优先修。

[argszero]

Your log is complete enough to place the crash between two specific lines, and both of your findings are real and independent. Source references below are master 687f282e86.

1. Why the host did not refuse — and which guard was skipped

removeBundle (packages/boot/plugin-manager/src/index.ts:686) has two guards, and HMR turns off the one that would have said no:

if (this.ownerContext.get('hmr') === undefined && (this.profile.startedBundles.includes(name) || ...)) {
  throw new ManagementFailure('stop-profile')          // :691, :694
}
const contributions = bundle.error === undefined ? this.bundleRows(name) : []
if (bundle.enabled) {
  await this.selectBundle(name, false)                 // :698 — persists the manifest without the entry
  Object.assign(result, await this.reload())           // :699 — unloads the bundle's rows
}
if ([...this.ctx.loader.entries()].some(entry => entry.fiber?.uid != null && ...)) {
  throw new ManagementFailure('bundle-in-use')         // :703
}

Your profile runs patchReload: live, so hmr is present and stop-profile is skipped by design — live removal is allowed precisely because HMR is supposed to unload the running code. The second guard survives, but it is evaluated at :703, i.e. after the deselect at :698 and after the reload at :699. It can therefore only catch a bundle that outlived its own reload; it cannot protect the bundle whose unload is the crash.

2. Why the half-state looks exactly like that

selectBundle(name, false) (:808) is the deselection: it filters the name out of dsh.profile.bundles (:823) and saves the profile manifest (:826), and it never touches dependencies — the dependency is dropped only by the later pnpm remove, inside the same change(...) call, after the reload. So losing the process at the reload produces exactly what you found: bundles entry gone, dependencies and node_modules intact, no pnpm run, no operation-* directory. Your evidence is not consistent with a partial pnpm run; it is consistent with a death between the manifest write and the pnpm step.

3. Startup reconciliation would not heal it as-is — and the existing function cannot either

reconcile() exists (packages/boot/plugin-manager/src/operations.ts:89), but it is called from exactly one place: :523, the tail of a package operation. Nothing calls it at boot, so your item 4 is correct as a gap.

It is also asymmetric in a way that matters for the fix: it only ever adds a bundle for a dependency that is new to that run —

for (const name of dependencies) {
  if (beforeDeps.has(name)) continue                                   // :99
  const metadata = bundleManifest(name, dir, anchor)
  if (metadata?.dsh?.bundle === undefined) { ...continue }             // :101
  ...
}

dshmarket is already in your dependencies, so beforeDeps.has('dshmarket') is true and the loop skips it. Adding a startup call alone would still not restore your profile. What a boot-time repair needs is the opposite rule: for every dependency whose own manifest declares dsh.bundle (the same predicate :101 already uses), restore the missing dsh.profile.bundles entry, and log what it restored.

4. On your item 1 — the host does protect itself, but only against the wrong thing

There is a self-protection guard, and it is the right idea keyed to the wrong predicate. Inside selectBundle, before the manifest write:

if (!enabled && previous.includes(name)) {
  if (this.protectsManager(name)) throw new ManagementFailure('management-required')   // :820-821
}

protectsManager (:837) fires when the bundle contributes any row whose module is in protectedModules (:68) — a hardcoded set of the host's own management modules (@deepseek-ai/dsh-plugin-manager, cordis-plugin-loader, cordis-plugin-include, dsh-api-gateway, dsh-client-ui-plugin-manager, …). It guards the bundle that provides the plugin manager. A market bundle is a consumer of that service over @Remote, so no row of it is in that set, and management-required never fires.

That is the exact class distinction your report is asking for: "cannot remove the component that manages plugins" already exists, and needs one step further — a bundle that is currently serving the request must not be removable either. Two shapes fit: key the refusal on the caller (the request's owning bundle), or let a bundle declare in its own manifest that it cannot be removed live, which the host then honours the way it honours protectedModules. Plus the reordering from above: evaluate bundle-in-use before selectBundle + reload, while the rows are still mounted — today the only pre-reload judgment is stop-profile, and HMR deliberately disables that one.

5. On your item 5 — the half-state is already reportable, without host changes

@argszero/dsh-activation-doctor (current release line 0.3.0) exists for exactly this state: it reads the profile's dependencies, filters by each package's own declared dsh.bundle, and diffs the result against dsh.profile.bundles. "Installed but never selected" is one of its reported stages — the state you are in now, where the package is present and nothing selects it. It reports; it does not repair. Until the host grows the boot-time repair in item 3, it at least replaces "edit package.json by hand" with a named diagnosis.

6. The orphaned lock is the sharper of your two findings

Your reading of withFileLock is right, and it is worse than "live PIDs are not taken over". holderExited (packages/util/atomic-write/src/index.ts:111) probes the recorded pid, and takeOverExitedLock (:150) removes the lock only when that returns true. Line :119 refuses even when the recorded pid is process.pid — "a runtime whose probe cannot see itself must not take over its own lock". So the very process that orphaned the lock is excluded from reclaiming it in-process, by design: recovery is operator-only, exactly as you found. saveManifest (operations.ts:84) is one of its writers, so every manifest write from the plugin manager sits behind that lock — which is why the whole plugin surface went down, not just the update path.

Two remedies that fit the existing design: allow takeover past a staleness bound even for a live pid (a manifest write is seconds, not minutes), and give the failure a named exit instead of a bare atomic-write: timed out waiting for the writer lock at <path>. Your dsh profile unlock idea is the right shape for the second.

Agreed with your priority: the lock is the one to fix first — it converts one bad update into a profile that cannot be repaired from the UI at all.

[ltmroberthk915]

宿主侧新现场：repair 之后磁盘已修复，但运行中的 host 不重挂载 → 整组工具静默消失

承接上面关于 reconcile()（只在包操作尾部调用、boot 不调用、且只处理"新出现的依赖"）的分析。这里补充一种它和 boot 修复都救不了的形态：修复动作发生在宿主已经启动之后。

时间线（UTC+8，profile desktop，patchReload: live）

时间	事件
10-18 01:42:51 / 01:51:02	pnpm 操作把 dsh-free-search 0.9.1 从依赖中摘除（.plugin-manager/logs/operation-*/pnpm.log 里的 - dsh-free-search 0.9.1）
01:53:27	宿主重启（PID 60428），此时运行组合里没有该插件
01:56:27	应用自动 repair，生成 package.json.repair-97-20261018-015627；与当前文件 diff 显示 repair 把 dsh-free-search 写回 dependencies 和 dsh.profile.bundles
01:59 起	会话里 9 个工具整组消失：advanced_search / cache_search / domain_search / free_search_test / multi_search / platform_search / research / video_search / weather；请求头只剩宿主自带的 web_search / web_fetch

现场特征

1. 是一条 tool-removal 同时删掉 9 个工具（source = tool-registry），不是逐个失败；
2. UI 没有任何提示，模型侧只得到 Error: unknown tool "domain_search"，看起来像单个工具坏了；
3. 磁盘侧全对：package.json 里依赖与 bundles 条目都在、node_modules/dsh-free-search 完整、node -e "import('dsh-free-search')" 正常导出。

也就是说，manifest 与 live tree 之间的漂移是完全不可观测的：用户、UI、模型三方都拿不到"这个插件没有被挂载"这一事实，只能从 unknown tool 反推。@argszero/dsh-activation-doctor 能报 "installed but never selected"，但它比对的是 manifest ↔ dependencies；本例里 manifest 已经被 repair 修好，漂移发生在 manifest ↔ 运行中的挂载集合，这一层目前没有工具能报。

两点建议

1. 任何写 dsh.profile.bundles / dependencies 的路径（包括 repair）在宿主存活时，要么触发一次 reload()，要么显式置 "restart required" 状态并在 UI 常驻——否则会出现"磁盘已修好、功能仍缺失"的永久落差，用户无从判断该不该重启；
2. tool-removal 目前只是 developer 消息里的一条静默事件。当移除原因是"整个插件离线"时，建议升级为一条会话可见的提示（例如在系统提示里写明"以下插件已离线：dsh-free-search"），否则 agent 只能靠猜测某个工具为何报 unknown tool。

（同一事故的市场侧线索已追加在 dsh-market/dsh-market#900：already-installed 更新失败 + 回滚不可验证 → 插件被摘除 → 10-18 当天市场日志 0 条。）