Loader should tolerate plugin failures: skip the failing entry instead of failing the whole profile

[lyf-yulu]

Problem

When any loader entry fails to apply, @deepseek-ai/cordis-plugin-loader throws immediately and rolls back, so the entire profile fails to boot — core included, together with every healthy plugin.

Evidence (cordis-plugin-loader/lib/index.js):

if (failures.length === 1) throw failures[0];
if (failures.length > 1) throw new AggregateError(failures, "loader entries failed to apply");
// ...followed by rollback of already-applied entries

Why this hurts (real scenario)

A core upgrade takes down the whole harness as soon as one third-party plugin has not caught up.

Third-party plugins pin exact core version lines through peerDependencies, e.g.

@deepseek-ai/dsh-agent => 0.1.2-rc.1 || 0.1.2-alpha.5

Because of prerelease semver rules, 0.1.5-rc.1 does not satisfy ^0.1.2-rc.1. So upgrading the core 0.1.2-rc.1 -> 0.1.5-rc.1 makes such plugins fail to load, and since the loader is fail-fast, the server does not start at all — not just the outdated plugin, everything is down.

The user is then forced to either stay on an old core (missing new models/features such as deepseek-flash / V4.1 Flash), or hand-disable every incompatible plugin before every upgrade.

Proposed behavior

The core is the subject; a single plugin failure should not take down the harness. An opt-in tolerance mode would fix it, e.g.

- id: loader
  config:
    tolerateEntryFailures: true      # or: onEntryFailure: "disable"

Behavior: an entry that throws is disabled with a warning (logged and surfaced in the plugin inventory / settings UI), the remaining entries apply normally, and the app boots. Strict fail-fast stays the default, so this is backward compatible.

There is precedent inside the repo: @deepseek-ai/dsh-mcp-client already exposes failOnStartupError (default false) so an unreachable MCP server does not block activation.

Additional value

• Enables incremental core upgrades: upgrade the core, keep healthy plugins working, and let outdated ones return automatically once they ship compatible versions.
• Lets the plugin inventory show "loaded / disabled (failed)" instead of an all-or-nothing boot.

[PerryLink]

+1, and three things that may be useful for the design.

A second shape of trigger. In #5926 the entry that aborted boot was a current plugin whose registration path hit a first-party defect, not a version pin. So the motivating case is not limited to stale peerDependencies - I won't re-derive it here, the detail is in #5926 and #6105.

A failure class a loader-level flag cannot see. At 0.1.5-rc.1 that same defect surfaced silently instead: the throw landed inside the plugin's inject callback fiber, the plugin's channels were never mounted, and every custom route returned a bare HTTP 405 while the entry itself applied without error (#5926's follow-up). So there are two outcomes - "failed to apply" and "applied, registered nothing" - and only the first reaches the loader. That matters for the inventory half of the proposal: packages/host/plugin-inventory/src/index.ts:73 currently reports enabled: !entry.disabled, which would read green in the second case. A capability-level signal would be needed alongside the entry-level one.

Two details from the current code (vendor/loader/src/config/group.ts, 0.1.5-rc.1):

• The path is transactional, not only fail-fast. EntryGroup.update() creates every entry concurrently with Promise.allSettled (:71), throws on a single rejection (:79) and aggregates several (:80), and the catch block then disposes every newly created entry, re-creates the previous configuration, and rethrows (:85-104). So tolerateEntryFailures changes the commit model rather than layering a tolerance check on top of it. Which of these it means needs to be named, because they differ in what the profile looks like afterwards: partial commit (keep the successes, mark the failures disabled, accept the new config), versus keeping the transactional update and only suppressing the abort. (Two edge paths are worth noting while specifying it: :75 returns early when the containing tree is disposed, discarding rejections entirely, and :103 reports an AggregateError when the rollback itself failed, after this.data has already been set to the old config.)
• Suppressing the throw is not sufficient on its own. The abort is not only in the loader: assertEntriesLoaded (packages/boot/app-boot/src/index.ts:688) and assertEntriesActivated (:722) independently throw for entries that failed to load or did not activate, and the latter runs as the final audit (:814). The loader tolerance has to be matched at that layer too, or boot still fails one step later.

One more thing about the config shape: the Loader is mounted programmatically - await ctx.plugin(Loader) at packages/boot/app-boot/src/index.ts:801, not as a profile row - so there is no loader entry today for a config: tolerateEntryFailures block to sit under. The option needs a config path as well as the behaviour.

Agreed on the precedent: dsh-mcp-client's failOnStartupError, opt-in and default-off, is the right model.

Disclosure of scope: loader, inventory and boot lines read from the 0.1.5-rc.1 tree; the carrier case is from #5926 and #6105, whose boot error is from 0.1.3-alpha.2 while the loader citations are from 0.1.5-rc.1. I measured the throw in that package's own test environment, not in a full dsh web profile.