[bug] Plugin-tree boot crash-loops when a plugin imports an export the bundled @deepseek-ai package no longer provides (dsh-run2skill ↔ dsh-typert-protocol RemoteError)

[wfeng707-crypto]

Summary

Installing a third-party plugin (dsh-run2skill@0.4.0) whose code imports
RemoteError from @deepseek-ai/dsh-typert-protocol makes the whole web
profile unable to start: every boot dies with
plugin tree failed to load: ... The requested module '@deepseek-ai/dsh-typert-protocol' does not provide an export named 'RemoteError',
and the launcher restarts it endlessly (~every 11 s), producing thousands of
crash-loop entries. A single broken plugin row takes down the entire tree
instead of being reported as one failed entry.

Environment

• App: DeepSeek Harness desktop (launcher + hub), profile web
• Runtime: /Applications/DeepSeek Harness.app/Contents/Resources/dsh-runtime
  • dsh / @deepseek-ai/dsh-typert-protocol = 0.1.0-rc.6
  • dsh-typert-protocol exports (rc.6): Remote, RemoteScope, TypertLookupFailure, TypertRemoteService, bindTypertRemote, isTypertRemoteSegment, remoteMethods — no RemoteError
• Profile plugins dir: ~/.dsh/profiles/web/node_modules (pnpm), plus a fallback mirror of runtime deps at ~/.dsh/profiles/node_modules/@deepseek-ai/* that plugins resolve @deepseek-ai/* bare imports against
• Plugin: dsh-run2skill@0.4.0, lib/index.js:5:
  import { RemoteError, TypertRemoteService } from "@deepseek-ai/dsh-typert-protocol";
  its peerDependencies declare @deepseek-ai/dsh-typert-protocol: 0.1.2-rc.1 (npm dist-tag next), while the shipped runtime provides 0.1.0-rc.6 (dist-tag latest) which removed RemoteError
• OS: macOS; hub Node v26.7.0 (homebrew)

Evidence (logs)

~/Library/Logs/DeepSeek Harness/launcher.log — the failing pattern:

Error: dsh: plugin tree failed to load: failed to apply loader entry include (cordis:include): failed to import loader entry run2skill (dsh-run2skill): The requested module '@deepseek-ai/dsh-typert-protocol' does not provide an export named 'RemoteError'
    at updateError (.../cordis-plugin-loader/lib/index.js:299:9)
    at Entry._init (.../cordis-plugin-loader/lib/index.js:519:10)
    ...
    at async Include._apply (.../dsh-app-boot/lib/index.js:238:3)
  [cause]: file:///Users/wangfeng/.dsh/profiles/web/node_modules/dsh-run2skill/lib/index.js:5
      import { RemoteError, TypertRemoteService } from "@deepseek-ai/dsh-typert-protocol";
               ^^^^^^^^^^^
      SyntaxError: The requested module '@deepseek-ai/dsh-typert-protocol' does not provide an export named 'RemoteError'

• does not provide an export named 'RemoteError' appears 5,545 times in launcher.log before the fix
• hub.log: "Plugin Hub 已启动（profile=web）" repeated ~every 10.7 s (unbounded restart loop; 1,116 system.start entries)
• Restart races also produced EADDRINUSE: address already in use 127.0.0.1:3080 while the previous instance still held the port

Root cause

A version-skew named-export mismatch at module instantiation, made fatal by the loader:

1. The plugin was built against the next protocol line (0.1.2-rc.1), which exports RemoteError.
2. The running app bundles latest (0.1.0-rc.6), which removed RemoteError.
3. ESM throws SyntaxError when the named export is missing — this is a load-time failure, independent of whether the symbol is ever called.
4. cordis-plugin-loader treats any failed include as plugin tree failed to load, the boot process exits, and the launcher restarts it → crash loop with no backoff and no isolation of the offending row.

What we did locally (workaround, not an upstream fix)

• Disabled the plugin row first (fastest止血): cordis.patch.yml - id: run2skill / disabled: true
• Then patched the installed copy: removed the RemoteError top-level import, kept a module-local class RemoteError extends Error so the two throw new RemoteError(...) sites keep their wire shape; re-enabled the row; verified the module imports cleanly and the tree boots.

Suggested fixes / asks

1. Fail soft per entry. A plugin include that fails to import/activate should be recorded as one failed entry (visible in hub UI / plugin inventory) while the rest of the tree still boots — not abort the whole profile. At minimum, avoid the unbounded auto-restart loop when the tree is in a deterministic bad state.
2. Actionable diagnostics. When a profile plugin imports @deepseek-ai/* through the fallback mirror, compare the resolved package's actual export surface against the import list (and the plugin's declared peer range vs. resolved version) and report e.g.:
   run2skill imports RemoteError from @deepseek-ai/dsh-typert-protocol; runtime provides 0.1.0-rc.6 (no such export; plugin wants 0.1.2-rc.1)
   instead of a buried nested-cause stack.
3. Install-time preflight. dsh plugin add could statically check named @deepseek-ai/* imports of the plugin against the bundled mirror before writing the composition.
4. Document/align rc lines. Plugin authors targeting dist-tag next currently break on latest runtimes with no version check; consider enforcing peer ranges or publishing a compatibility matrix (this is not about the specific plugin — any @deepseek-ai/* symbol removal has the same failure shape).

Happy to attach full logs or run additional probes.

[argszero]

Excellent report — precise, with logs and a clean workaround. I verified the export-surface claim against the published artifacts, and the real root cause is one layer deeper than version skew: the desktop runtime is on the stale latest line while the plugin ecosystem targets next.

Artifact evidence

@deepseek-ai/dsh-typert-protocol dist-tags right now:

• latest → 0.1.0-rc.6
• next → 0.1.2-rc.1
• alpha → 0.1.2-alpha.5

Published lib/index.js comparison:

• 0.1.0-rc.6: zero occurrences of RemoteError — it does not exist on that line.
• 0.1.2-rc.1: 7 occurrences — RemoteError is defined and exported (index.ts re-exports ./remote-error.ts).

So RemoteError was added somewhere between rc.6 and the 0.1.2 line (not removed — the naming in your report is backwards, but the failure shape is unchanged). Your dsh-run2skill@0.4.0 was built against next (its peer range 0.1.2-rc.1), and the app's runtime resolved latest → 0.1.0-rc.6. ESM named-import mismatch at load time, exactly as you traced.

The deeper root cause: latest is stale, and an official app ships it

0.1.0-rc.6 is not just missing RemoteError — it predates the entire 0.1.1-rc.2 and 0.1.2 line. This is the stale-latest problem this ecosystem has hit repeatedly (the @deepseek-ai/dsh-* packages keep latest pinned to an old release while next carries the maintained line). What's new and important in your report: an official DeepSeek Harness desktop build is itself resolving latest and shipping the ancient line to end users. That turns a dist-tag annoyance into a user-facing compatibility cliff — every plugin written against the current (next) line breaks the shipped app, with no version check anywhere in the chain.

The fix that actually removes this whole class: advance latest to the current release line (or have the desktop runtime pin an explicit non-latest version). Your four asks are all good; with that reframing I'd rank them:

1. Fail soft per entry (highest leverage): a broken plugin include currently takes down the whole tree with no backoff — and this loader first-error-kills-all behavior has now bitten in several forms (REQUEST_EXTENSION 报错把 cause 链完全吞掉：终端、会话日志、Web UI 三处都看不到真实原因 #5173-family: one bad entry kills the entire prepare/extension set; your crash-loop adds the no-backoff restart dimension). Per-entry isolation + visible "one failed entry" is the systemic fix and would have contained your incident to a red row instead of 5,545 log lines.
2. Actionable diagnostics: export-surface diff (resolved version's actual named exports vs the import list + declared peer range) is very implementable — the loader already resolves the package; comparing its export list is a small step.
3. Install-time preflight: same export-surface check at dsh plugin add time, before the row is written.
4. Align rc lines — really the dist-tag fix above.

Workaround note: your module-local class RemoteError extends Error patch is the right interim shape (keeps the two throw sites' wire shape without the import). Given the ecosystem split, plugin authors genuinely cannot know whether their users' runtime is on latest or next until the tag gap is closed — worth stating loudly in whatever channel the release owners watch.