[Bug] Web 插件管理页在读取失败后一直显示“正在读取插件…”

[elio040208]

现象

Web 的「插件管理」页面有时一直显示“正在读取插件…”，刷新和添加插件按钮不可用，页面也没有错误提示或重试入口。我在 Chrome 中遇到过这个现象；同一个正在运行的 Host，在另一个浏览器中能立即显示插件列表。清除用户安装的插件后，web profile 只包含 @deepseek-ai/dsh-base 和 @deepseek-ai/dsh-web-app，Chrome 中仍会卡住。Chrome 那次底层请求失败的具体原因尚未确认。

可稳定复现的客户端问题

在 packages/client/ui-plugin-manager/src/client/manager-store.ts 的 PluginManagerController.read() 中，让 ctx.remote.pluginInventory.list() 返回 rejected Promise（例如连接中断），或返回一直 pending 的 Promise；后面的 pluginManager.listBundles() / listPlugins() 也有同样问题。当前方法只有 try/finally，没有在失败时把状态从 loading 改为 error，也没有为一直 pending 的读取设置截止时间。因此页面可以无限停在“正在读取插件…”。

期望行为

读取失败或超过合理等待时间时，页面应退出加载状态，显示已有的错误和“重试”界面，允许用户再次读取；刷新失败时应保留此前加载成功的列表。

环境

• DeepSeek Harness 源码版 0.1.7-rc.1
• macOS，Web profile，Chrome
• 已排除额外安装的 profile 插件；只有 base 和 web-app bundle

相关代码：PluginManagerController.read()。

[argszero]

I traced this to PluginManagerController.read() in packages/client/ui-plugin-manager/src/client/manager-store.ts, and to the three Remote reads it makes:

pluginInventory.list()
pluginManager.listBundles()
pluginManager.listPlugins()

Those three calls have no failure exit and no deadline of their own. read() sets status = 'loading' and then hands the result straight through:

try { ... } finally { ... }      // no catch

So there are two ways to arrive at exactly the reported state, and both are terminal:

• a read that rejects propagates out of read(), finally runs, the status is never moved off loading — no message, no retry;
• a read that never settles does the same thing, silently, for as long as the page is open.

What makes this worth reporting as a store-side bug rather than a transport one: the page already ships the exit. PluginManagerPage renders a distinct error sentence plus a Retry button for status === 'error', and the store reaches error whenever a read answers { ok: false }. That path is unreachable only because the method call itself never returns. Nothing about the design is missing; the read just has no way to stop waiting.

One detail worth stating precisely, because it narrows the diagnosis: packages/typert/protocol/src/types.ts already folds carrier failures (connection closed, dispatch error) into the { ok: false } branch. So a dead socket does not reject — it answers. What rejects is an assembly fault: the call could not be made at all. That means the durable half of the gap is the deadline, not "handle a dropped connection" — a read that is simply never answered is the case no existing branch covers.

A plugin that closes the user-visible half

I published @argszero/cordis-plugin-remote-read-guard (0.1.1) — source, tests and the honest statement of its boundary are in https://github.com/argszero/cordis-plugin-remote-read-guard.

It is a browser-half cordis plugin. When the Web shell mounts it, a sibling plugin fiber wraps each of the three reads on the remote namespaces with a deadline (15 s default, configurable) plus rejection/synchronous-throw normalisation into a legal RemoteFailure (packages/typert/protocol/src/remote-error.ts), so the store receives { ok: false } and reaches the error branch it already has:

the read	without the plugin	with the plugin
answers { ok: true } in time	passed through	passed through, untouched
answers { ok: false } in time	store's error branch	the read's own failure, unchanged
never answers	loading forever	{ ok: false } → error + Retry
rejects	escapes read(), loading forever	{ ok: false } → error + Retry
answers after the deadline	—	still reported (onEvent, kind late), so "slow" and "gone" are distinguishable

It never cancels a read, never retries one, and never invents a value.

Two things I had to verify rather than assume, in case anyone else wraps these namespaces:

• the seam works by replacing the method on the service instance: Object.defineProperty(ctx.get('remote.pluginInventory'), 'list', { value: wrapper }) — checked against the real @deepseek-ai/cordis@4.0.4, and the original is restored on dispose;
• the dotted name must appear verbatim in inject (inject: ['remote', 'remote.pluginInventory']); injecting only remote does not re-arm the wrapper when the namespace is reinstalled.

The bound is the plugin's value; the fix belongs in core

I want to be explicit about the ceiling here. The plugin restores the designed error path, which is what the reporter's symptom needs, but it is a wrapper — a fourth read added to the store tomorrow is not covered until someone extends it, and a hung read still holds its request object behind the page. The store itself should stop being unbounded:

• a catch around the three reads in manager-store.ts so a rejection lands on error with a message instead of escaping;
• a timeout on the reads (or a shared helper for bounded Remote reads) so an unanswered call reaches the same branch;
• while we are there, read() should stay idempotent under concurrent calls, since Retry and a remount can both be in flight.

Happy to adjust the plugin if a canonical shape for bounded Remote reads lands in core — it is a thin wrapper by design and can be deleted the day read() has its own exit.

Install

- insert:
    - id: remote-read-guard
      name: '@argszero/cordis-plugin-remote-read-guard'

The package ships that row as cordis.patch.yml via dsh.bundle.patch, so a profile/bundle can include it directly. Tests cover the shipped bundle evaluated through a fake window.__ModuleLoader__ in a real cordis app whose namespaces have the gateway's shape, judged by the controller's own store logic (read() without a catch, as it is in the product) — the measured claim being that a hanging or throwing read reaches error instead of loading. One arm runs a child process that awaits nothing but the hanging read, because a deadline that only fires while something else keeps the event loop alive is the same silent non-answer in a different costume (that was a real bug in 0.1.0; 0.1.1 fixes it and pins it as a defect arm).

[yuxu4468-hash]

补一份同根因的实测（DSH 桌面端 0.2.0-rc.2 / Windows 11 / profile desktop）。

「插件页读不出来」和「清单带 BOM 启动即崩」是同一个函数。 readProfileManifest（@deepseek-ai/dsh-app-boot/lib/index.js:835，裸 JSON.parse(raw)、不剥 BOM）不只走启动路径：@deepseek-ai/dsh-plugin-manager 直接 import 了它（dsh-plugin-manager/lib/index.js:10，:227/:239/:425/:460/:616/:626 都在调）来做 bundle 列表。所以 BOM 存在而应用已经在运行时，先坏的不是启动而是插件页：

POST /api/pluginManager/listBundles
{"ok":false,"error":{"code":"gateway/internal",
 "message":"Unexpected token '', \"{\r\n    \"n\"... is not valid JSON"}}

同一文件、同一宿主、不重启的单变量对照：

profiles/desktop/package.json	pluginManager/listBundles
带 UTF-8 BOM（EF BB BF）	ok:false — Unexpected token '' … is not valid JSON
剥掉 BOM（3 字节）	ok:true，返回 23 个 bundle

也就是说 readProfileManifest 里加一句 raw.replace(/^\uFEFF/, '') 可以同时修掉「启动即崩」和「插件页一直读不出来」（就是本条讨论的现象）。我这边发现时 BOM 还在，若先重启，那个 profile 就会按 #8574 描述的样子直接崩。

BOM 是谁写的（我这次不是 app）：那次重写唯一的语义变化是给 dependencies 与 dsh.profile.bundles 各加一个插件；留下的文件是 4 空格缩进、": " 双空格、值对齐（PowerShell ConvertTo-Json 风格），而 DSH 自己写这份清单是 JSON.stringify(manifest, undefined, 2) + "\n"（dsh-plugin-manager/lib/index.js:235）；写入前留下的备份无 BOM。与 #8574 的复现一致（PS 5.1 的 -Encoding UTF8 默认带 BOM）。

建议：在这一处剥离 BOM，并让报错点名「文件以 UTF-8 BOM 开头」——BOM 的来源可能是 PowerShell 5.1、某些编辑器或第三方安装脚本，用户不该靠猜（#6758 的论点）。