Client plugin-boot failures are swallowed: “The client Loader did not provide an error message” (a plugin's rejected apply() → whole app into recovery mode)

[zczsw123]

What happened

A third-party client plugin (dsh-ears@0.3.2) failed to boot on DSH 0.1.7-rc.1 (Desktop 2.0.14) and the
desktop dropped the whole app into recovery mode. The only message available anywhere was:

dsh-plugin-desktop: renderer boot failed (plugins: dsh-ears): The client Loader did not provide an error message.
RendererStartupFailure: Renderer boot failed for 1 plugin(s)

The lifecycle-events/startup.jsonl inside the exported diagnostics bundle is more useful but still does not
carry the cause:

{"eventName":"renderer.boot.failed",
 "details":{"rendererStatus":"failed","failureReason":"renderer-failed",
            "pluginCount":1,"pluginIds":["dsh-ears"]}}

The actual cause — found only by reading the plugin's source — was that the client contribution's
apply() rejected:

async function apply(ctx) {
  const disposeRemote = await ctx.remote.$mount(TYPERT_REMOTE);   // ← rejected on 0.1.7
  ...
}

because the plugin's generated Typert codecs no longer satisfy the new contract
(typert-loader: dsh-ears invocation "dsh-ears#dshEars/listRoutes" result codec has no create() factory;
requireStrictCodec now demands mode: "strict", a string typeSymbol, and a create() factory).

So the chain is: codec contract drift → $mount rejects → apply() rejects → client Loader marks the
plugin failed → renderer boot fails → recovery mode, and every layer between the cause and the user
discards the reason.

Why it matters

• Diagnosis took hours and needed source reading plus a diagnostics bundle; the UI said only
  "did not provide an error message".
• A plugin that cannot mount its remote takes down the entire profile rather than degrading to
  "this plugin's UI is unavailable". Users then have to switch to another profile to get back in.

Suggestions

1. Surface the cause. When a client plugin's apply() rejects, capture and log the rejection
   (name + message + stack) instead of reporting only pluginIds. If the client Loader genuinely
   sees no error, log what it did observe (which module, which phase, what the promise settled with).
2. Include it in the diagnostics bundle. lifecycle-events is the right place — a failureDetail
   field next to failureReason would have made this a five-minute diagnosis.
3. Consider failing soft. A failing contribution's remote mount (or its whole client module) could
   disable that plugin's UI/slot contributions while letting the rest of the renderer boot. The current
   behaviour means one third-party plugin's contract drift locks the user out of the app.

Reproduced with DSH Desktop 2.0.14 / kernel 0.1.7-rc.1 on Windows; the same plugin worked on the
0.1.5-rc.2 line. Happy to provide the diagnostics bundle or a minimal reproduction plugin if useful.

[zczsw123]

A concrete case study: one swallowed client-plugin failure cost 3 app restarts and ~2 hours

I reported the swallowing behaviour in the opening post. Here is a fully diagnosed example from a real third-party plugin (dsh-ears on Desktop 2.0.14 / kernel 0.1.7-rc.1), as evidence for why the client Loader should surface the reason.

What the user saw (every time):

dsh-plugin-desktop: renderer boot failed (plugins: dsh-ears): The client Loader did not provide an error message.
RendererStartupFailure: Renderer boot failed for 1 plugin(s)

…and the whole app dropped into recovery mode, with no message anywhere: not in the app log, not in the host log, not in the diagnostics bundle's lifecycle-events (which only carries failureReason: "renderer-failed").

Why it was expensive: the plugin actually had six independent 0.1.7 incompatibilities (removed settings.register, strict Typert codec create(), renamed icon set, an inlined second copy of the codec manifest inside the client bundle, no exported Config → no settings write path, and configEditor writes re-composing the entry). Because nothing was reported, each one had to be found by bisecting with full app restarts, and two of them looked identical from the outside ("boot failed, no message").

Naming the plugin helped; naming the reason would have helped much more. If the Loader logged the rejection it caught — error.name, error.message, first stack frame, plus which slot/mount step threw — the whole chain would have been visible in one run. The pluginIds field already proves the Loader knows which plugin; extending it to why is the small change that turns this class of failure from hours into minutes.

Suggested minimal shape (happy to file as an issue if the repo enables them):

{"eventName":"renderer.boot.failed",
 "details":{"pluginIds":["dsh-ears"],"failureReason":"renderer-failed",
            "pluginErrors":[{"id":"dsh-ears","name":"Error",
                             "message":"typert-loader: dsh-ears invocation \"dshEars/listRoutes\" result codec has no create() factory",
                             "at":"client.js:apply"}]}}

Also worth considering: a plugin whose apply() rejects during boot could be quarantined (disabled for the session, surfaced in the UI) instead of taking the entire app into recovery mode — a single third-party plugin should not be able to do that.

[zczsw123]

Second case of the same family: an inject dependency that never resolves makes a plugin's UI silently contribute nothing

The opening post is about a plugin whose apply() rejects and whose error is swallowed. Here is a sibling failure mode with the same cost profile — no exception at all, so nothing is even available to swallow:

On Desktop 2.0.15 / kernel 0.1.7-rc.2, the New-Session agent-preset picker disappeared entirely. The plugin (@deepseek-ai/dsh-client-ui-agent-preset) registers its hero control and header label inside a single call:

ctx.inject(["slots", "conversation", "sessions", "uiWorkspace"], (scope) => {
  const chip = scope.slots.register({ name: "conversation.hero.agentPreset", … }, …);
  const label = scope.slots.register({ name: "conversation.session.header.actions", … }, …);
}, "ui-agent-preset: new-session chip and header label");

The client runtime provides slots, sessions and uiWorkspace — but not conversation. So the callback never runs and both contributions are silently absent: live slot inspection reports catalog.registration: [], no error is raised, nothing is logged, and the diagnostics bundle has nothing to show. Meanwhile the plugin's second inject (slots.inject("settings.section")) works fine, which makes the symptom look arbitrary ("some of the plugin is there, some isn't").

Diagnosing this required cross-checking two inspection surfaces (the live Slot tree and the client Service directory) — i.e. the same "hours of bisection" cost as the swallowed-rejection case, just without an exception anywhere in the picture.

Suggestion. When a client plugin's inject dependencies stay unsatisfied beyond startup, report it on the plugin's own diagnostic surface (the plugin page / a "pending dependency: conversation" line) rather than leaving the plugin silently half-mounted. Together with the apply() rejection case in the opening post, that would cover both ways a client contribution can vanish without a trace.

[zczsw123]

Correction to my previous comment (peer review caught a misread field).

In the comment above I described this case as "an inject dependency that never resolves, so the plugin silently contributes nothing". A reviewer re-checked and found that my supporting evidence read the wrong field:

• catalog.registration: [] on a kind: "single" slot is the registration-options schema (which parameters a registrant may pass), not a list of who registered. The sibling kind: "list" slot makes this obvious — its value is literally [{name:"id"…},{name:"order"…},{name:"label"…}]. A single-occupant slot takes no options, hence [].
• The same sibling slot's live occupants include { id: "agent-preset", order: -10, active: true }, matching the plugin's registration parameters exactly ⇒ that plugin's inject callback did run and its registrations are active.

So the "pending dependency" framing is withdrawn for this case: the contribution is registered and the feature still doesn't appear, which points at the rendering path rather than dependency resolution.

Two related observations from the same review do still stand and are worth keeping in the discussion's theme ("contributions can vanish without a trace"):

1. One inject callback registered two unrelated UI features (a New-Session control and a session-header label), so a single upstream cause removes both at once — no partial degradation.
2. The slot's contract was more permissive than the plugin's dependency: its props mark the conversation hooks optional (MaybeSnapshotSelectorHook<ConversationSnapshot>, inputActions: InputActions | undefined), while the plugin listed conversation as a hard inject requirement. Using ctx.get("conversation") + an undefined check (the documented optional-access form) would have been the more faithful match.

Either way the diagnosis cost is real: a registered-but-invisible contribution produces no error, no log and no diagnostic entry — the same observability gap as the swallowed-apply() case in the opening post.

[zczsw123]

Correction / withdrawal of the "pending dependency" framing in my earlier comment.

The case I described (a New-Session control that never appeared) turned out to be neither a swallowed error nor an unsatisfied dependency: the control is gated by a user setting. With 通用设置 → "代码工作工具" (code-work tools: trajectory view, turn code diff, and Agent-preset switching in a new conversation) switched off, the picker is intentionally not rendered; turning it on makes it appear immediately. The plugin even receives the flag as a hook — developerTools: ctx.configForms.developerTools.enabled — which I quoted in my own report without realising it was the gate.

So the contribution was registered, the dependency situation was irrelevant, and the observable outcome was a feature-flagged-off control. Withdrawing the case from this discussion's evidence base.

That said, it sharpens exactly the point this thread is about — observability of absent client contributions:

• a control that is supposed to be absent (flag off) is indistinguishable, from the outside, from one that failed to appear: no error, no log, no diagnostic entry in either case;
• the only way we resolved it was by finding the flag by hand.

Hence the ask is unchanged but now better motivated: for gated contributions, surface the reason where the user expects the feature ("preset switching is disabled — enable 代码工作工具"), and keep the general recommendation that client-side contribution failures carry an id + reason on the plugin diagnostic surface. Between "flag off", "dependency pending" and "apply() rejected", all three currently look like nothing happened.