Third-party plugin exception in a session observer takes down the whole host

[WHIFabian]

A third-party plugin's session observer threw, and the whole host exited instead of that plugin degrading.

A plugin (@goodreaddy/dsh-time-machine@0.1.24) raised inside its ctx.on('session/event', …) handler. The host aborted on the first turn:

dsh: fatal load failure: DOMException [DataCloneError]: () => current could not be cloned.
    at structuredClone (node:internal/per_context/domexception:76:18)
    at getConfig (<profile>/node_modules/@goodreaddy/dsh-time-machine/lib/index.js:69:42)
    at autoSnap  (<profile>/node_modules/@goodreaddy/dsh-time-machine/lib/index.js:88:10)
    at Object.<anonymous> (<profile>/node_modules/@goodreaddy/dsh-time-machine/lib/index.js:110:11)
    at Object.apply (<app>/dsh/node_modules/@deepseek-ai/cordis/lib/index.js:921:20)
    at invokeContainedSessionObservers (<app>/dsh/node_modules/@deepseek-ai/dsh-session/lib/index.js:1230:20)
    at Session.append (<app>/dsh/node_modules/@deepseek-ai/dsh-session/lib/index.js:1473:50)
    at ReactLoopAgent.turn (<app>/dsh/node_modules/@deepseek-ai/dsh-agent-loop/lib/index.js:943:17)
    at ReactLoopAgent.kick (<app>/dsh/node_modules/@deepseek-ai/dsh-agent-loop/lib/index.js:889:22)

Environment. DSH Desktop 0.2.0-rc.2 (Electron 44.0.0, node 24.18.1, darwin arm64, profile desktop). Third-party bundles loaded from the profile's own node_modules.

The plugin's own bug is already handled upstream. GooDAnDReaDY/dsh-time-machine#6 root-caused it — on DSH 0.1.7+/0.2.0 the loader hands schema-declared volatile fields to apply() as { get() } accessor objects, which structuredClone cannot clone — and it is fixed in 0.1.25. I am not re-reporting that bug.

The platform concern is the blast radius. One third-party plugin raising inside a session observer takes down the entire host. The shell's only recovery is "disable third-party plugins, back up the profile patch, and restart", and that path resets dsh.profile.bundles to the stock web bundle list — so the desktop-specific bundles are dropped along with the offending plugin:

@deepseek-ai/dsh-base
@deepseek-ai/dsh-web-app
@deepseek-ai/dsh-experimental-agent-team-profile   ← dropped
@deepseek-ai/dsh-experimental-auto-review          ← dropped
@deepseek-ai/dsh-experimental-schedule-bundle      ← dropped
@deepseek-ai/dsh-experimental-voice-input-bundle   ← dropped

The user loses more than the plugin that failed and has to rebuild the list by hand. (Observed live: the bundle list went from 8 entries to 2.)

There is also no way out from the command line: dsh plugin --profile desktop … is refused with profile "desktop" is managed exclusively by the Electron application, so a user whose host is bricked by a single plugin cannot remove just that one bundle from the shell.

Suggestion. Contain exceptions raised by session-event observers per plugin — skip or disable the throwing plugin and surface a non-fatal reload diagnostic — instead of exiting the host, consistent with how a failed bundle load is already reported as a non-fatal reload error. If a hard abort is intentional for load-time failures, consider distinguishing an observer throw during Session.append from an actual load failure.

Side note (not a DSH bug, but it affects reproduction): a fresh pnpm add @goodreaddy/dsh-time-machine still resolves to the broken 0.1.24, because pnpm's minimumReleaseAge (24 h) skips 0.1.25 until it has aged. So a plugin that has already been fixed stays unreachable for a day, and the failure above is easy to hit right now. Pinning the version is the only workaround on the user side.

[aashish254]

you've root-caused it right, there are two separate things here.

the plugin bug itself is fixed in 0.1.25. pnpm is just holding it back for 24h because of minimumReleaseAge. you can bypass that for this one install by setting minimum-release-age=0 when you add it in the profile dir, that gets you the fixed version today instead of tomorrow.

the blast radius point is valid too. your stack trace shows the throw coming out of invokeContainedSessionObservers with nothing catching it per plugin, so it goes straight up through session.append and kills the host. containing observer exceptions per plugin and reporting them the way failed bundle loads already are is the right fix. worth opening as an issue since that's a maintainer decision.

[WHIFabian]

Thanks — that matches what I found. Two things back:

On the workaround. Verified here just now: --config.minimum-release-age=0 does resolve ^0.1.25, while the bare --minimum-release-age=0 spelling does not (the command fails), so the --config. prefix matters. As of today it is moot anyway — 0.1.25 is now ~29 h old, so a plain pnpm add @goodready/dsh-time-machine resolves to ^0.1.25 with no flag.

On "worth opening as an issue". That is exactly the problem: deepseek-ai/deepseek-harness has the issue tracker disabled (has_issues: false), and there is no separate issue repo under the org either — dsh-libreoffice-kit and dsh-node-addon-require-builtin are disabled too. Discussions is the only channel open, which is why this is posted here rather than as an issue. If the observer-containment work should be tracked as an issue, the tracker has to be enabled (or a repo that accepts issues created) — this one has ~240k stars and no issue intake at all.

If there is a canonical place maintainers prefer for platform-level reports, I am happy to move or re-file this there.