Plugin loading lacks fault isolation: one failing plugin takes down the entire plugin tree

[ybkin1]

Summary

Plugin loading is not fault-isolated: if a single plugin throws during load/activation, the error aborts the whole plugin loading pass, and every other plugin — including healthy, unrelated ones — becomes unavailable. We observed this in practice when one locally installed plugin failed with ReferenceError: inject is not defined at load time; the entire plugin tree was unavailable for that run until the offending plugin was removed. We would like per-plugin isolation: catch load errors per plugin, degrade gracefully, and keep the rest of the tree running.

Background & Evidence

• During a routine restart (2026-08-25), one locally installed plugin threw ReferenceError: inject is not defined on its activation path.
• The exception was not contained to that plugin: the remaining healthy plugins did not come up for the run. Restoring full service required removing/fixing the single broken plugin — there was no per-plugin disable switch to fall back on.
• With several plugins installed (first-party and community), any one of them can take down the whole extension surface. This makes plugin upgrades risky: one broken plugin update turns into a full outage of plugin functionality, and the failure is hard to diagnose because the surviving plugins are also gone.

Failure Mode or Reproduction

1. Install two or more plugins; confirm all of them load on startup.
2. Introduce a load-time error in one plugin (for example a reference to an undefined symbol in its activation path, or install a plugin built against a newer plugin API).
3. Restart dsh.

Observed: the failing plugin's exception aborts the loading pass; the remaining healthy plugins do not load. Expected: only the offending plugin is marked failed (with its error surfaced per plugin), and the rest load normally.

Proposed Fix

• Wrap each plugin's discovery/load/activation in its own try-catch boundary.
• On failure: record per-plugin status (name, error, stack), log one clear error line naming the plugin, and continue loading the remaining plugins.
• Surface a startup summary of plugin states (loaded / failed / skipped) and provide a way to disable a single plugin via configuration or CLI, without uninstalling it.
• Optionally: a "safe mode" (load no plugins) for recovery, and retry of failed plugins only on explicit reload/HMR, so a broken plugin cannot repeatedly disturb boot.

Additional Context

• dsh: @deepseek-ai/dsh 0.1.1-rc.2 (developer preview)
• OS: Windows 10 x64 (build 10.0.18363)
• Node.js: v22.23.2

[liyangbing]

这个问题会直接影响用户是否敢安装第三方 Runtime。建议把“Host 插件加载隔离”和“插件内部运行时沙箱”分成两层处理：

• Host 层：单个插件的 discovery / activation 失败时，记录插件名、阶段、错误和 stack，继续加载其他插件；同时保留一个不加载用户插件的 recovery profile，避免只能重装 DSH。
• Runtime 层：插件不要修改 DSH 核心文件；把自己的 workspace、sessions、credentials、MCP bridge 和 audit 数据放在明确边界内，并让 disable / uninstall 后的残留可检查。
• 验收应覆盖 load-time throw、依赖版本不兼容、插件卸载中断、profile 切换和冷启动；不能只验证“正常插件能启动”。

SandBase Harness 可以作为一个第三方 runtime 集成参考：它通过 DeepSeek Harness bundle 示例 接入，runtime 状态在自己的 workspace 中管理，并提供 安装恢复说明。这不能替代 DSH Host 的 per-plugin fault isolation，但可以帮助验证“插件失败不应等于数据和恢复路径消失”的边界。

[ybkin1]

Follow-up to my own report above, after a deeper read of the sources. The observed behavior stands — one plugin throwing ReferenceError: inject is not defined left the entire plugin tree unavailable for that run until the offending plugin was removed — but the mechanism I implied, and therefore the fix I asked for, were both wrong.

What I got wrong. I framed this as "plugin loading lacks fault isolation" and asked for each plugin's activation to be wrapped in its own try-catch. The shipped sources show the framework already does exactly that: every plugin runs in its own fiber, and an activation error caught by a plugin's fiber stops only that fiber (it logs the error, records it on the fiber, and deactivates just that plugin) — other plugins' fibers are untouched at this layer. My proposed fix was asking for something that already exists.

Where the all-or-nothing actually comes from. The plugin loader applies the whole entry list as a single transaction: it creates the entries via Promise.allSettled, and if a single entry is rejected, it aborts the update and rolls back the entire group — newly created entries are disposed and the previous configuration is restored. On a fresh boot the "previous configuration" is empty, so the net effect of one broken plugin is that no plugins come up for the run. That is precisely my reported incident: per-plugin containment at the fiber layer, overridden by a deliberate transactional rollback in the loader above it.

The reshaped ask. Keep transactional semantics where they protect live reconfiguration, and contain failures at boot instead:

1. On the initial application of the composed tree, apply entries best-effort — mark failing entries failed and let the healthy ones come up.
2. Print a startup summary of plugin states (loaded / failed / disabled), naming the failing entry and its error, so diagnosis does not hinge on one loader error line.
3. Expose the existing per-entry disabled flag. Loader entries already support a persisted disabled option (the loader auto-writes it when a plugin's fiber is disposed), but nothing user-facing exposes it — dsh plugin only forwards add/remove/why to pnpm — so recovery today is uninstall-or-edit-files. During the failed boot the rollback removes the entries entirely, so the flag would not have saved that run — it is the recovery switch for the next one.

Environment: @deepseek-ai/dsh 0.1.1-rc.2 (developer preview), Windows 10 x64; the 2026-08-25 incident date in my original report stands.

Thanks to the maintainers and the community — this correction comes from a deeper source read before taking the thread further. I hope the two-layer mechanism is useful regardless of how the boot-policy question is decided.