0.1.5-rc.1：connection.rpc.handle() 无法注册插件 RPC 通道（浏览器端一律 HTTP 405）

[mcmichealkaluna-debug]

EN summary: On DSH 0.1.5-rc.1 (Windows 11, Node v26.8.2, @deepseek-ai/cordis 4.0.2), connection.rpc.handle(channel, handler) always throws cannot get property "webServer" without inject. The exception is swallowed inside effect, so the channel is never registered on the webserver and every browser-side connection.rpc.call() hits the static fallback and gets HTTP 405. Any plugin using this public API breaks (reproduced with dsh-mnemon 0.5.5/0.5.6 and dsh-billing 0.4.1). Root cause looks like the carrier-neutral change in dsh-client-connection: register() dereferences owner.webServer on the connection service's own context, which no longer injects webServer. A 12-line overlay workaround is included below.

环境

• DSH @deepseek-ai/dsh 0.1.5-rc.1（Windows 11 / Node v26.8.2 / profile web）
• @deepseek-ai/cordis 4.0.2
• 受影响插件实测：dsh-mnemon 0.5.5（0.5.6 代码相同）、dsh-billing 0.4.1

现象

升级到 0.1.5-rc.1 后，凡是通过 connection.rpc.handle() 注册的浏览器 RPC 通道全部失效：

请求	结果
POST /dsh-mnemon-settings/get	405
POST /dsh-mnemon-read/status-summary	405
POST /dsh-mnemon-read/source-management-catalog	405
POST /billing/balance	405

前端表现为面板报 transport failure … HTTP 405（如记忆系统面板显示 Mnemon 尚未就绪）。

对照：走 ctx.webServer.register() 直接注册的路由（例如 /dsh-skill-picker/list）返回 200 —— webserver 与浏览器鉴权本身正常，问题只出在 rpc.handle 这一条链路。

宿主侧自检：webServer.match('/dsh-mnemon-read/status-summary') → no-match，即前缀路由从未注册（405 来自静态回退：非 GET 一律 405）。

最小复现（不依赖任何第三方插件，12 行）

// probe.js —— 通过 dsh --profile web --patch ./overlay.yml 挂载
export const name = 'probe';
export const inject = ['connection', 'webServer'];
export function apply(ctx) {
  console.log('ctx.webServer =', typeof ctx.webServer);
  ctx.webServer.register({ kind: 'prefix', path: '/probe-direct',
    handler: (req, res) => { res.writeHead(200); res.end('ok'); } });
  console.log('direct register ->', !!ctx.webServer.match('/probe-direct/x'));
  try {
    ctx.connection.rpc.handle('/probe-raw', async () => ({ ok: true }));
    console.log('rpc.handle ok ->', !!ctx.webServer.match('/probe-raw/x'));
  } catch (e) {
    console.log('rpc.handle THREW:', e.message);
  }
}

# overlay.yml
- insert:
    - id: probe
      name: /abs/path/to/probe.js
      config: {}

实际输出：

ctx.webServer = object
direct register -> true
rpc.handle THREW: cannot get property "webServer" without inject

调用方上下文确实注入了 webServer（第 1 行），直接 webServer.register() 也正常（第 2 行）——失败只发生在 rpc.handle() 内部。

根因分析

@deepseek-ai/dsh-client-connection（0.1.5-rc.1）：

get rpc() {
  const owner = this.ctx;                                                 // 连接服务自身的上下文
  return { handle: (channel, handler) => this.register(owner, channel, handler) };
}
register(owner, channel, handler) {
  ...
  return owner.effect(() => owner.webServer.register(route), `...`);       // ← 抛错点
}

0.1.5 把 connection 改为 carrier-neutral（README：「Host half always provides the carrier-neutral RPC and exact GET/HEAD/POST route registries. When a Web carrier is present it also owns the sole /api route …」）之后，该上下文不再注入 webServer；而 @deepseek-ai/cordis@4.0.2 的 ReflectService.handler.get 对「未注入即访问服务」是抛错而非返回 undefined：

const error = new Error(`cannot get property "${prop}" without inject`);
...
throw enhanceError(error);

于是注册在 effect 内失败并被静默吞掉 —— 通道丢失。因为 rpc.handle 是同步抛出，插件侧若不 try/catch 会直接报错，但没有任何线索指向 webServer。

补充：内核 200+ 个包中没有任何一处调用 rpc.handle，因此该回归不在上游自测覆盖范围内。

建议修复（任一）

1. 注册时使用持有 webServer 的上下文（连接插件自身的 fiber 上下文），而不是 tracker 当前作用域的 this.ctx；
2. 按 carrier 分流：无 Web carrier 时只写入 carrier-neutral 注册表，有 Web carrier 时再桥接，避免每次注册无条件解引用 owner.webServer；
3. 顺带建议：解析不到 webServer 时不要静默，至少打一条 warn —— 否则插件作者完全看不到发生了什么。

临时规避（本机已采用，不影响 node_modules）

用 12 行覆盖层插件把 owner 换成注入了 webServer 的上下文：

export const name = 'dsh-conn-rpc-compat';
export const inject = ['connection', 'webServer'];
export function apply(ctx) {
  const proto = Object.getPrototypeOf(ctx.connection);
  const original = proto.register;
  proto.register = function (owner, channel, handler) {
    return original.call(this, ctx, channel, handler);   // owner = 本上下文（有 webServer）
  };
}

实测效果：/dsh-mnemon-read/status-summary、/dsh-mnemon-settings/get、/billing/balance 三个通道由 no-match → 命中；浏览器端 405 → 200；记忆系统面板恢复真实数据（存储位置 已连接、记忆引擎 dsh-mnemon 0.5.5 插件运行正常、记忆空间 1/1 · 83 条激活记忆、项目档案 50 份活跃）。上游修好后该插件即可删除。

相关

• 同一个根因的插件侧报告（含根因与规避方案）：[Issue]: DSH 0.1.5-rc.1 下浏览器端 RPC 全部返回 405（上游 connection.rpc.handle() 回归，附根因与临时规避） omdsh-dev/dsh-mnemon#219

（另注：0.1.5 把全部 @deepseek-ai/dsh-* 包统一编号为 0.1.5-rc.1，第三方插件按旧口径声明的 peerDependencies（如 ^0.1.0-rc.6）会大面积失配。这是编号口径变化，运行时无影响，但会在兼容性面板产生大量误报，或可作为单独话题讨论。）

[PerryLink]

Reproduced in-tree on 0.1.5-rc.1, and there is one correction worth making first: the caller side is not the lever here.

This is the same defect as #5926. Both reports describe owner.webServer as "the connection plugin's own context", and the #5926 thread asks whether the calling plugin simply needs to declare webServer itself. I measured that directly with the package's own test harness (Context plus a structural webServer double), varying only (a) where the carrier is provided and (b) what the caller injects:

carrier provided on	caller	connection.rpc.handle
the context that mounts Connection	a plugin, inject: ['connection']	ok
the context that mounts Connection	a plugin, inject: ['connection', 'webServer']	ok
a sibling plugin row	a plugin, inject: ['connection']	throws
a sibling plugin row	a plugin, inject: ['connection', 'webServer']	throws
a sibling plugin row	the root context	ok

Rows 3 and 4 are identical, so declaring webServer in the calling plugin changes nothing - your probe is row 4, which is why ctx.webServer reads fine one line above the throw. The variable is the position of the carrier relative to the accessor's fiber chain. In a real profile the carrier is always a sibling row (dsh-host-webserver), so no third-party plugin can work around this from its own side; it has to be fixed in dsh-client-connection.

Why CI is blind to it: packages/client/connection/tests/node-half.host.spec.ts:281-328 provides the carrier with ctx.provide(...) on the same context that mounts the plugin - rows 1 and 2, the only two that pass.

Where the binding lives, for the fix:

• src/rpc-host.ts:79-86 - get rpc() / get fetch() scope the returned registry to the Context reading the service.
• src/rpc-host.ts:158-182 - register() ends in owner.effect(() => owner.webServer.register(route), ...). This is the only place in the package that dereferences webServer from a caller-scoped context.
• src/rpc-host.ts:139-156 - registerFetchRoute() writes a private map and never touches webServer; the /api route mounts those from index.ts:119-139, inside ctx.inject(['webServer'], webCtx => ...).

So the dedicated-channel registry is the one path that is not carrier-neutral, and the package already contains the pattern that is.

Two data points on fixes:

• The one-line change from [Bug] connection fails to start when a third-party plugin registers an HTTP channel: cannot get property 'webServer' without inject #5926 (src/index.ts:69, inject = ['webServer', 'credentials']) does make all five shapes pass - I ran it. It also turns an optional carrier into a hard dependency, which contradicts packages/client/connection/README.md:28: "The Host half always provides the carrier-neutral RPC ... When a Web carrier is present it also owns the sole /api route". A shell-owned carrier deployment would then wait for a web server it does not have.
• The shape that keeps that contract: give register() the same structure as registerFetchRoute() - record the channel and its fetch handler in a private map under the caller's fiber, and let the existing ctx.inject(['webServer'], webCtx => ...) block at index.ts:119-139 mount a prefix route per registered channel. handle then has no carrier dependency, and the neutral registry is the single source of truth for both carriers.

Blast radius, for prioritisation: nothing in packages/ calls rpc.handle. The only kernel use of this service is rpc.intercept at packages/api/gateway/src/index.ts:199, and intercept never dereferences webServer. That is why this stayed invisible until ecosystem plugins hit it.

Disclosure of scope: measured on 0.1.5-rc.1 with the package's own vitest runner (Node 26, the same suite that passes 16/16 on that commit); both runs are reproducible from a 5-case spec. I did not run a full dsh web profile end to end. Happy to post the spec if a starting regression test is useful.

[drscrewdriver]

这个是切换rpc之后的适配问题吗？

[Robin1987China]

复现、定位、修复、验证 —— 都在隔离环境里做完了，补一条完整结论。

这不是竞态，是必然抛错。 connection 服务持有的是插件自己的 ctx（该行声明 inject: [webRuntime]），而 register() 读的是 owner.webServer：

// dsh-client-connection/lib/index.js
const owner = this.ctx;                                   // :541 —— 只有 webRuntime
  handle: (channel, handler) => this.register(owner, channel, handler),   // :543
  ...
  return owner.effect(() => owner.webServer.register(route), ...);        // :618 —— 必然抛错

官方 /api 为什么没事：它走的是另取的 ctx ——

ctx.inject(["webServer"], (webCtx) => {                    // :758
  webCtx.effect(() => webCtx.webServer.register(route), ...);   // :781
});

包自己的注释写着它在“webServer 存在时”才挂载浏览器传输 —— 而面向插件的 API 却无条件假设它存在。

复现证据（隔离 DSH_HOME + 独立端口）

LAB-PROBE: rpc.handle() THREW: cannot get property "webServer" without inject
POST /api       -> 401   (对照，已注册)
POST /lab-probe -> 405   (未注册，落到静态处理器)

修复（一行）

- id: connection
  inject: [webRuntime, webServer]

修后：插件日志变成 returned without throwing (disposer: function)，POST /lab-probe 变成 401（已注册）。

我把它打包成了组合包（官方分发形态，验证过以 bundle 形式交付同样有效）：dsh-connection-rpc-fix —— npm i dsh-connection-rpc-fix，或直接把上面两行贴进 cordis.patch.yml。