[BUG] [0.1.7-rc.1] strict-codec format change makes an out-of-tree Typert Remote plugin fail activation and blocks the whole Web UI

[Saneman1-kz]

Environment

• Host: @deepseek-ai/dsh@0.1.7-rc.1 (npm dist-tag next), web profile, Windows 11
• Working host: @deepseek-ai/dsh@0.1.5-rc.3 (dist-tag latest)
• Plugin: dsh-mcp-mgr@0.2.0 + dsh-mcp-mgr-ui@0.2.0 (latest published, 2026-09-03), installed in
  $DSH_HOME/profiles/web/node_modules, listed in dsh.profile.bundles
• Node 24.19.0, pnpm 11.25.0

Symptom

Booting the same profile under 0.1.7-rc.1 never reaches the app. The boot screen shows:

Failed to load plugins
dsh-mcp-mgr-ui
web boot: 1 entry did not activate
dsh-mcp-mgr-ui: failed

The entry's client fiber ends in state failed (3), the whole page stays on the boot card, and
the failure text names no cause. On the host side the same entry sits in loading (1).

Root cause measured

The plugin's apply() mounts its generated Typert Remote and that mount is rejected:

validateCodec → validateInvocation → validate → register → mountContribution → apply

@deepseek-ai/dsh-typert-registry validates strict codecs differently in the two generations:

0.1.5-rc.3 (lib/client.js):

function validateCodec(codec, subject) {
  if (codec.mode === "src-json") return;
  validateNonempty(`${subject} type symbol`, codec.typeSymbol);
  if (typeof codec.schema.parse !== "function") throw new Error(`typert: ${subject} strict codec has no parse() method`);
}

0.1.7-rc.1 (same file):

function validateCodec(codec, subject) {
  if (codec.mode === "src-json") return;
  validateNonempty(`${subject} type symbol`, codec.typeSymbol);
  if (typeof codec.create !== "function") throw new Error(`typert: ${subject} strict codec has no create() factory`);
}

and the emitted descriptor shape changed with it:

• dsh-mcp-mgr@0.2.0/lib/typert.remote-client.js (generated by the 0.1.5-era tooling):
  { mode: 'strict', typeSymbol, schema: <zod schema> } — 12 schema: entries, no create:
• @deepseek-ai/dsh-api-session-controller@0.1.7-rc.1/lib/typert.remote-client.js (shipped):
  { mode: 'strict', typeSymbol, create: () => <zod schema> }

So a Remote contribution produced by the older generator is rejected by the newer registry, the
rejection surfaces only as failed, and the client boot audit throws
web boot: N entry did not activate.

Why it blocks everything

One out-of-tree client plugin that cannot activate aborts the whole client boot, so the Web UI is
unusable even though every first-party entry is healthy. This is the client-side face of the
fail-fast behaviour already raised in #6134, and the diagnostic hides the cause (the stored fiber
error is not printed, only the state), which is exactly the "applied, registered nothing /
failed with no reason" gap described there.

What I would like to know / propose

1. Is the strict-codec shape change intentional and permanent for 0.1.7+? If yes, what is the
   supported migration path for an out-of-tree plugin that was generated with the 0.1.5/published
   tooling — must every such package regenerate lib/typert.remote-client.* with the new
   generator before a host upgrade?
2. Would it be acceptable for validateCodec to accept both shapes during the transition, e.g.
   treat a strict codec as valid when it exposes either schema.parse or create, so previously
   published Remote artifacts keep mounting? The same question applies to validateSchemas
   (schema.create).
3. Independently of 1/2: the client boot audit should name the rejection reason on the boot card
   (it already computes one for pending/import failed), because today the only way to find the
   cause is a debugger session.

Reference points I found while narrowing this down: #5618, #2981 (external Typert protocol
recognition), #3167 (out-of-tree Remote contribution registry), #4013 (the 0.1.1 adapter contract
change that broke an installed plugin the same silent way), #6134 (loader tolerance).

Reproduction (compact)

1. Copy the current web profile to an isolated DSH_HOME, keep dsh-mcp-mgr and
   dsh-mcp-mgr-ui in its node_modules and dsh.profile.bundles.
2. Boot that profile with 0.1.7-rc.1 on a spare port.
3. Open the page: the boot card fails with the message above; with DevTools paused on exceptions,
   the first app rejection is the validateCodec throw inside ctx.remote.$mount(...).
4. Boot the same profile with 0.1.5-rc.3: the entry activates and the MCP settings tab appears.

[PerryLink]

你这条正好撞上版本标签的坑——请先确认你在哪一条线上

1. 你贴的两个版本，正是 npm 上的一对"新旧错位"

你写的 working host : @deepseek-ai/dsh@0.1.5-rc.3   ← 这是 npm 的 latest（**旧**）
你写的 failing host : @deepseek-ai/dsh@0.1.7-rc.1   ← 这是 0.1.7 线（当时是 next）
当前最新的 next     : @deepseek-ai/dsh@0.1.7-rc.2   （比 rc.1 又新一个版本）

⇒ 所以你的对照是"旧版能跑、新版不能跑"，而不是"最新版有回归"。这很重要，因为它决定维护者会去看哪段代码——0.1.7 线引入 strict codec 的那次变更，而不是最近的提交。

2. 请务必先在 0.1.7-rc.2 上复现一次

rc.1 → rc.2 之间有 346 个提交，其中就有针对启动期条目处理的改动（例如 fix(boot): report skipped profile bundles once per start）。所以：

npm i -g @deepseek-ai/dsh@next      # = 0.1.7-rc.2

若 rc.2 上仍然失败 ⇒ 你的报告基线应写成 0.1.7-rc.2，说服力最强；若 rc.2 上恢复正常 ⇒ 这条在 rc.2 已解，可结。

3. 这条报告的真正价值在"破坏性变更 + 无迁移路径"

你描述的链路是：strict codec 变更 ⇒ 外部插件（dsh-mcp-mgr*）激活失败 ⇒ 整个 Web UI 起不来。无论最终是"插件该适配"还是"核心该兼容"，都有一件事值得单独提：

升级后应当有可诊断的提示——现在用户只看到 Failed to load plugins / web boot: 1 entry did not activate，而"这是插件与新 codec 不兼容"这个结论要用户自己去推。

建议把诉求写成两条：① 若这是有意的破坏性变更，请在 changelog / 启动提示里点名它（哪个 codec、影响哪类插件）；② 对于一个客户端插件激活失败就整页不可用这件事，请评估是否应当降级（与 #7835 那条"非关键插件失败不应中止整棵树"是同一类诉求）。

4. 一个请求

请把启动日志里该插件失败的那几行原文（含具体异常）贴进正文。现在正文给的是 UI 上的两行摘要，而真正的异常才是维护者要的。

5. 一条边界

我确认的是你两个环境对应的 npm 标签关系（0.1.5-rc.3 = 旧 latest；0.1.7-rc.1 = 0.1.7 线；当前 next = 0.1.7-rc.2）。"strict codec 变更具体改了什么"我没有核对——那需要你那条失败异常的原文才能定位。

[Saneman1-kz]

Thanks for the triage — here is the follow-up you asked for.

Reproduced on the current next (0.1.7-rc.2)

Confirmed today: next is still @deepseek-ai/dsh@0.1.7-rc.2, latest is still
@deepseek-ai/dsh@0.1.5-rc.3, and the plugin is still the latest published
dsh-mcp-mgr@0.2.0 / dsh-mcp-mgr-ui@0.2.0.

Same isolated-profile setup, host upgraded to 0.1.7-rc.2: the client boot still fails with

Failed to load plugins
dsh-mcp-mgr-ui
web boot: 1 entry did not activate
dsh-mcp-mgr-ui: failed

so the right baseline is 0.1.7-rc.2, not 0.1.7-rc.1.

The raw exception (as requested)

There is no log file or log line that carries it, so this is a debugger capture rather than a
quoted log excerpt — which is itself part of the problem (see ask #1 below). Method: DevTools open
on the page, Debugger.setPauseOnExceptions: "all" armed before navigation, then read the value of
the first application rejection. It is raised after the host has already started serving the page:

promiseRejection
Error: typert: dsh-mcp-mgr#mcpMgr/apply result strict codec has no create() factory
    at validateCodec (…/plugins/??@deepseek-ai/dsh-typert-registry/client.js:3690:50)
    at validateInvocation (…:3653:4)
    at DescriptorStore.validate (…)
    at DescriptorStore.register (…)
    at ClientRemoteService.mountContribution (…)
    at Object.apply (…/plugins/??dsh-mcp-mgr-ui/client.js)
variables: codec = Object ; subject = "dsh-mcp-mgr#mcpMgr/apply result"

What each channel actually contains, so nobody goes looking for dsh.log:

• Host stdout/stderr: only dsh web: http://127.0.0.1:<port>/?token=…. The rejection never crosses
  the process boundary, and the host entry stays in loading.

• Browser console (DevTools → Console), the only printed line:

  Error: web boot: 1 entry did not activate
  dsh-mcp-mgr-ui: failed
      at VS (…/assets/index-Q6zc2uHV.js:124:61817)
      at HS (…/assets/index-Q6zc2uHV.js:124:61281)
      at async XS.run (…/assets/index-Q6zc2uHV.js:126:4421)
  

• The detailed text itself: nowhere. It lives in the failed fiber's _error, and the audit prints a
  reason only for pending and import failed fibers; for failed it prints the bare state. That
  is why the body could only quote the UI summary.

If you want the message without attaching a debugger, the shipping audit already holds the value it
withholds: in 0.1.7-rc.2 the loop that builds the failure list has s.fiber.error in scope and
pushes only the state for the failed branch (else o.push(\${a}: ${u}`)), while the pendingandimport failed` branches both carry a reason. Adding the stored error there would make the same
page print:

web boot: 1 entry did not activate
dsh-mcp-mgr-ui: failed — typert: dsh-mcp-mgr#mcpMgr/apply result strict codec has no create() factory

I state that as a code-reading, not as a run: I could not execute the patched audit against the live
tree, because the client module system does not expose the Cordis context (system.loader is
undefined on the object handed to create()), so my only runtime evidence for the message itself
remains the debugger capture above. If it helps, a one-line change in the failed branch is all
this asks for.

Descriptor-level detail for the same contribution:

dsh-mcp-mgr@0.2.0/lib/typert.remote-client.js:
  { mode: 'strict', typeSymbol, schema: <zod> }   // 12 schema: entries, no create:
@deepseek-ai/dsh-api-session-controller@0.1.7-rc.2/lib/typert.remote-client.js:
  { mode: 'strict', typeSymbol, create: () => <zod> }

Scope, as far as I can measure it

This is not specific to the MCP manager. Any package whose client face carries Typert artifacts
produced by the older generator hits validateCodec at mount time, because the registry now
requires codec.create while those artifacts expose codec.schema. The plugin itself cannot
adapt: the decision point is inside mountContribution, before any plugin code runs, and the
generated file is the plugin's own published artifact.

What would settle this

1. Can you confirm whether the create() factory is now the only accepted strict-codec shape, or
   whether the registry intends to keep accepting schema-based artifacts? If the break is
   intentional, the concrete question is: which generator release emits create(), and must every
   already published out-of-tree package regenerate its lib/typert.remote-client.* before the
   host is upgraded?
2. If the change is intentional but the intent is not "every installed plugin must be rebuilt in
   lockstep", would you accept a transitional validateCodec / validateSchemas that treats a
   strict codec as valid when it exposes either schema.parse or create?

Two smaller asks, both visible in the transcript above

1. The client boot audit should surface the reason it already holds. It prints a reason for
   pending and for import failed, but for a failed fiber it prints only the state, so
   dsh-mcp-mgr-ui: failed is all the user gets while the actual message sits in the fiber. In my
   case the entire diagnosis required attaching a debugger to the page.
2. Consider whether a non-critical client plugin that fails to activate should abort the whole
   client boot (same class as dsh-mobile boot crashes on Windows when a GNU coreutils whoami.exe shadows System32 in PATH #7835). Right now the outcome is that a healthy host serves nothing
   usable until the user manually removes the bundle from dsh.profile.bundles.

Happy to test a patch or a rebuilt plugin artifact on Windows if that shortens the loop.

[mnshun]

Update: reproduced on the current @deepseek-ai/dsh@0.1.7-rc.2 line on macOS arm64 (Node.js 25.6.0) with dsh-plugin-shop@0.8.3. The host reports:

typert-loader: dsh-plugin-shop invocation "dsh-plugin-shop#shop/catalog" parameter codec has no create() factory
Failed to load plugins
dsh-plugin-shop
web boot: 1 entry did not activate dsh-plugin-shop: failed

The plugin-side report is tracked at LivXue/dsh-plugin-shop#61. The published descriptor uses the pre-0.1.7 strict shape (schema.parse) while the 0.1.7 loader requires codec.create().

Suggested DSH-side fixes:

1. Treat the strict-codec change as a versioned protocol migration. During the transition, accept/adapt the legacy schema.parse shape, or make the loader emit an explicit compatibility error that names the required DSH/generator version and resolved package version.
2. Keep optional/out-of-tree plugin failures isolated from the core web profile. Disable the failing entry, continue booting healthy entries, and expose the disabled entry in the plugin inventory. This is related to Loader should tolerate plugin failures: skip the failing entry instead of failing the whole profile #6134.
3. Put the package name, entry/invocation, root cause, and a recovery action (disable/update plugin) on the web boot card. The current generic Failed to load plugins screen hides the actionable cause.
4. For EADDRINUSE on port 3080, report the existing listener/PID and suggest --port <port> or --port 0 instead of presenting a long uncaught stack trace.

Please also include the resolved module path/version in loader diagnostics; this would make mixed or stale profile dependency trees distinguishable from a plugin-generated descriptor bug.

[PerryLink]

你这条正好把我上一个回复里留着的那个问题答掉了

1. 你的报错与加载器校验逐字对应

packages/typert/loader/src/index.ts:282：

throw new Error(`typert-loader: ${pkgName} ${subject} has no create() factory`)

而你的原文是：

typert-loader: dsh-plugin-shop invocation "dsh-plugin-shop#shop/catalog" parameter codec has no create() factory

⇒ pkgName = dsh-plugin-shop、subject = invocation "dsh-plugin-shop#shop/catalog"、缺的是 parameter codec 的 create() 工厂。完全落在 :282 这一支，不是别的路径。

2. 你这两条信息恰是我上一条回复缺的证据

我在给楼主的回复里留了一个二选一：该包是本仓的、还是 profile 里装的，以及是否在最新版上仍复现。你用一条评论把两个都答了：

• out-of-tree：dsh-plugin-shop@0.8.3（第三方插件）；
• 在 0.1.7-rc.2 线仍复现（macOS arm64, Node 25.6.0）。

⇒ 结论因此收敛为：这是第三方 codec 与新契约不兼容（0.1.7 的加载器要求每个 codec 暴露 create()），不是本仓的回归。而本仓该做的两件事是：

1. 升级时的兼容性提示（现在只有 Failed to load plugins + 1 entry did not activate，用户要自己推）；
2. 失败的作用域（一个客户端插件不兼容就让整页不可用，与 #7835 / #7865 的"故障隔离"是同一类诉求）。

建议你把这两句直接补进主帖（尤其"已在 rc.2 复现"），这样楼主那条就不必再等版本确认了。

3. 一条给插件作者的定位

create() 工厂缺失是插件侧要改的（按新契约补上）。建议在正文里带上插件的 package.json 版本与它的 codec 注册处（哪一行声明了 parameter codec）——这样插件作者一看就知道改哪里，而不是只看到"注册失败"。

4. 版本提醒

⚠️ 当前最新就是 0.1.7-rc.2（tag dsh-v0.1.7-rc.2，npm next 也是它）⇒ 你的复现基线已经是正确的，不需要再升。只是别把核换成 latest（它仍停在 0.1.5-rc.3，更旧）：

npm i -g @deepseek-ai/dsh@next