[0.1.5-rc.1] connection.rpc.handle() always throws (cannot get property 'webServer' without inject) - all plugin RPC channels return 405

[hangmujun]

Summary

In @deepseek-ai/dsh@0.1.5-rc.1, the public connection.rpc.handle(channel, handler) API throws synchronously on every call, so no plugin RPC channel is ever registered on the web server. Browser requests for those channels fall through to the SPA/static handler, which answers 405 for any non-GET/HEAD request.

Environment

• @deepseek-ai/dsh 0.1.5-rc.1 (npm latest)
• @deepseek-ai/cordis 4.0.2
• @deepseek-ai/dsh-client-connection 0.1.5-rc.1
• Windows 11, Node v22.23.1, profile web
• Affected plugins observed: dsh-mnemon 0.5.5 / 0.5.6 / 0.5.7 (all ship the same code), dsh-vision-router 2.1.4

Root cause

packages/client/connection → HostConnectionService:

get rpc() {
  const owner = this.ctx;                                               // ← service's own context
  return { handle: (channel, handler) => this.register(owner, channel, handler), ... };
}

register(owner, channel, handler) {
  ...
  return owner.effect(() => owner.webServer.register(route), `client-connection: ${channel} rpc channel`);
  //                          ^^^^^^^^^^^^^^^ throws here
}

this.ctx inside the class resolves to the service's own context (the plugin's declared inject is ["credentials"]), not the reader-scoped context — even though the doc comment on the surrounding API says "scoped to the Context reading this service". With cordis 4.0.2, accessing a service that is not in that context's inject set throws instead of returning undefined:

cannot get property "webServer" without inject

Because the throw is synchronous inside handle(), the channel route never reaches webServer, and there is no log line anywhere — the failure is completely silent.

Why this is not a caller-side problem

Measured live in the running host (0.1.5-rc.1):

Check	Result
ctx.webServer on a context that injected ['webServer','connection']	accessible (true)
ctx.effect(() => ctx.webServer !== undefined) on the same context	accessible (true)
ctx.connection.ctx === ctx (reader-scoped proxy)	true
ctx.connection.rpc.handle('/probe', ...) from that same context	THROWS cannot get property "webServer" without inject
ctx.webServer.register({kind:'prefix', path:'/probe', handler}) directly	works, route appears

Since connection.ctx is the reader context and reader.webServer is provably readable inside an effect, the owner used inside register() cannot be that same reader context — it is the raw service context. So no amount of correct injection on the plugin side can work around it.

No package in the DSH core actually calls rpc.handle (verified by scanning every @deepseek-ai/* lib/**.js), so this regression is not covered by the in-repo test suite.

Observed impact

The web server prefix table contains zero plugin RPC channels:

post-upgrade prefixes: /api, /plugins, /dream-skin/api, /auto-compact/api,
                       /super-injector/api, /describe-image, /boot-guard,
                       /api/builtin-toggles, /open-in-app/icon, ...
  missing: /dsh-mnemon-read, /dsh-mnemon-write, /dsh-mnemon-settings,
           /dsh-mnemon-activation, /dsh-mnemon-pack, /dsh-mnemon-view,
           /dsh-mnemon-view-settings, /vision-router-settings

User-visible: the Mnemon memory panel shows Mnemon 尚未就绪 plus
transport failure for /dsh-mnemon-read/status-summary: HTTP 405, while all host-side tools keep working (they are in-process and never touch HTTP) — which makes the failure look like a plugin bug.

Suggested fix

Use the lenient accessor (or thread the reader-scoped context through explicitly):

-  return owner.effect(() => owner.webServer.register(route), `client-connection: ${channel} rpc channel`);
+  return owner.effect(() => owner.get('webServer').register(route), `client-connection: ${channel} rpc channel`);

Verified against the live 0.1.5-rc.1 process: with this change, rpc.handle() no longer throws, all 7 /dsh-mnemon-* prefix routes register, and the panel's requests stop returning 405.

Minimal reproduction

export const name = 'probe';
export const inject = ['connection', 'webServer'];
export function apply(ctx) {
  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')); // true
  try {
    ctx.connection.rpc.handle('/probe-raw', async () => ({ ok: true }));
    console.log('rpc.handle ok');
  } catch (e) {
    console.log('rpc.handle THREW:', e.message); // cannot get property "webServer" without inject
  }
}

Related

• Downstream report with the same root cause: [Issue]: DSH 0.1.5-rc.1 下浏览器端 RPC 全部返回 405（上游 connection.rpc.handle() 回归，附根因与临时规避） omdsh-dev/dsh-mnemon#219

[SISCHOI]

Independent confirmation from a third-party plugin author, with the version boundary measured rather than inferred.

Where: Windows 11 + WSL 2 (Ubuntu 24.04.4), Node 24.19, host built from @deepseek-ai/dsh@0.1.5-rc.1 / 0.1.5-rc.2 (in-box packages at the same version).

What I see

// plugin apply(ctx)
const connection = ctx.get('connection')            // present
connection.rpc.handle('/lab-probe', handler)        // throws
// Error: cannot get property "webServer" without inject

The channel never registers, so POST /lab-probe/<endpoint> falls through to the SPA fallback and answers 405 (on 0.1.0-rc.7 the same code answers 200). This matches the 405 in the opening post exactly.

It is not caller-side misuse. Injecting the web server as well does not help — verified with a probe plugin:

ctx.inject(['connection'], (c) => c.get('connection').rpc.handle('/a', h))            // throws "…webServer without inject"
ctx.inject(['connection', 'webServer'], (c) => c.get('connection').rpc.handle('/b', h)) // throws the same

(c.get('webServer') resolves fine in the second case; the throw comes from inside register(), which reaches for owner.webServer through the service context.)

Measured boundary (npm pack @deepseek-ai/dsh-client-connection@<ver>, checking the plugin-level inject list and apply shape):

version	plugin-level inject	apply	rpc.handle()
0.1.0-rc.7, 0.1.0-rc.8	["webServer"]	sync	OK
0.1.1-rc.1, 0.1.1-rc.2	["webServer"]	sync	OK
0.1.2-alpha.2 … 0.1.3-alpha.2	["webServer","credentials"]	async	OK
0.1.5-alpha.1, 0.1.5-alpha.2, 0.1.5-rc.1, 0.1.5-rc.2	["credentials"]	async	BROKEN

So webServer left the plugin-level inject list in the 0.1.5-alpha.1 line while register() still resolves it through the service context — which is also why the fix suggested in #6227 looks right to me.

Second-order effect worth knowing (same root refactor): because apply became async (it awaits browser-auth setup before constructing the service), a plugin that reads ctx.get('connection') synchronously in its own apply now gets undefined on 0.1.2-alpha.2 and later, and silently loses its web panel. Probe timeline on 0.1.5-rc.2: apply → hasConnection=false, ctx.inject(['connection'], …) → hasConnection=true (~4.4 s later). Deferring the mount to ctx.inject(['connection'], …) fixes that half; rpc.handle() still needs the host fix.

Workaround I did not adopt: registering the route directly on an injected webServer works (the in-box @deepseek-ai/dsh-api-gateway does exactly that for its own rows), but such a row bypasses the browser-token / host-origin fence that connection applies to its own channels, so a third-party plugin would be exposing an unauthenticated loopback endpoint. I kept the plugin failing loudly instead.

Full evidence (probe code, session archives, tool schemas, npm-pack sweep): https://github.com/SISCHOI/daruma/blob/main/docs/aegis/evidence/2026-09-11-latest-harness-compat.md

[Robin1987China]

确认你的诊断，并补上定位与已验证的修复。

抛错点在这里（与你的描述一致）：

// dsh-client-connection/lib/index.js
register(owner, channel, handler) {
  return owner.effect(() => owner.webServer.register(route), ...);   // :618
}

而 owner 是 this.ctx（:541），该行只声明了 inject: [webRuntime] —— 从来没有注入过 webServer，所以每次都抛，不是偶发。官方 /api 不受影响，因为它用的是 ctx.inject(["webServer"], ...) 另取的 ctx（:758）。

复现与修复验证

	插件日志	POST /lab-probe
修复前	THREW: cannot get property "webServer" without inject	405
修复后	returned without throwing	401（已注册）

修复就是给那一行补上它读的服务：

- id: connection
  inject: [webRuntime, webServer]

打包成了组合包（也验证过 bundle 形态可用）：dsh-connection-rpc-fix，或者直接贴上面两行进 cordis.patch.yml。