"Failed to load plugins" fatal screen offers no recovery action

[lhbsaa]

Summary

When a plugin client bundle fails to register, the whole GUI is replaced by a fatal "Failed to load plugins" screen with no recovery action on it.

Repro

Install a plugin whose client bundle registers a wrong id (e.g. loaded without registering "@scope/pkg" via __ModuleLoader__.load), then start the web UI.

Result

The app shows only the fatal screen (which entry failed, nothing else). The user must leave the app, manually edit profile config / node_modules (or use the CLI) to recover. For a desktop user this is a hard blocker.

Suggestions

1. Add "disable / remove this plugin and restart" actions directly on the error screen.
2. Keep listing the failing entry id (already shown) plus a one-line hint how it can be removed.

[taltara]

A second data point for this, with a different cause, plus a distinction I think matters for the fix.

Different cause, same screen. Mine was not a wrong id in __ModuleLoader__.load. It was a transitive node: import: I shared one module between the host half and the client half of my plugin - just a file of route-path constants - and that dragged the host's module graph into the browser bundle, so the client ended up requiring node:crypto. The shell's module table cannot answer that, and the result is byte-identical to yours:

failed to import loader entry (dsh-blueprint): client-modules:
require("node:crypto") missed the module table - not a platform seed word,
not a materialized module, and no registered package factory

Worth noting because the authoring mistake is invisible: nothing about sharing a constants module looks like it crosses a boundary, and the plugin builds and typechecks fine. The bundle only reveals it if you check what it actually requires - grep -o 'require("[^"]*")' lib/client.js is now a step in my build, and on a healthy client bundle it should print nothing outside the shell's module table.

The distinction. There are two failure severities here and they need different answers:

1. This one. The client bundle fails, the fatal screen replaces the GUI - but the process is alive. Host routes still serve, the CLI still works. A recovery action on the screen, as you propose, is entirely possible because there is something still running to render it.
2. A host-side row naming a module the profile cannot load. Cordis fails module resolution during boot and the process exits. There is no screen to put a button on, because there is no process. Recovery is hand-editing YAML.

Both are "one plugin takes down everything", which is the underlying ask, but only the first can be solved with a better error screen. The second needs either per-entry failure isolation or a pre-boot check, and I do not think a UI affordance can reach it.

For what it is worth I ended up building the second as a refusal rather than a recovery - my tool will not write a row whose package is not present in the profile, because after the write there is no running harness left to warn in. That check is extracted as dsh-overlay-check (MIT, Node only, no dependencies) if it is useful to anyone else writing overlays - it is one function, preflightOps, and it exists only because isolation does not. That is a workaround for one tool, not a fix for the platform, and I would much rather have the isolation.

Upvoted. The recovery actions you suggest would have saved me an afternoon on case 1.

[ylwl1997]

+1 — this fatal screen needs a recovery path.

We see the same user pain from the catalog side: many “Failed to load plugins” cases are one bad third-party plugin (missing webServer, bad schema, host/client graph leak), not a dead harness. When the UI offers only a brick wall, people can’t even dsh plugin remove … safely from the GUI.

A minimal recovery UX would already help a lot:

• name the first failing plugin / entry in the banner
• “Continue without this plugin” / open a degraded mode
• copy-pasteable dsh plugin --profile … remove <pkg>

Related feature ask with install-test data: #2603. Our install/load/run notes live at https://dshbase.com/plugins/directory/.

[ckqqqq]

try this:
dsh plugin remove @linxin666/dsh-web-ui-all[you plugins] --profile web