dsh-client-connection@0.1.5-rc.1: connection.rpc.handle() fails with "cannot get property webServer without inject" when called from a plugin's own ctx.inject(["connection"], ...) callback

[TangSuann]

Summary

HostConnectionService.register() (the implementation behind the public connection.rpc.handle(channel, handler) API) accesses this.ctx.webServer directly. But this.ctx is the Context captured when HostConnectionService was constructed inside dsh-client-connection's own apply() — a Context that was never injected with webServer. Only a separate, later ctx.inject(["webServer"], webCtx => ...) callback inside the same apply() function (used for mounting the fixed /api route) actually has webServer access.

As a result, every third-party plugin that calls the documented public API connection.rpc.handle(channel, handler) to register its own RPC channel throws at registration time:

Error: cannot get property "webServer" without inject

This breaks the plugin's channel silently: the plugin's own try/catch around the outer ctx.inject(["connection"], ...) call does not see this error (it's thrown inside a nested nested nested effect/inject callback that is not run synchronously — see reproduction below), so the plugin logs no error and appears to have registered successfully. The channel is simply never mounted. Any HTTP request to that channel's path then falls through to the SPA static-file fallback route (dsh-host-frontend-static), which returns 405 for any non-GET/HEAD method instead of reaching the plugin's handler.

Environment

• @deepseek-ai/dsh: 0.1.5-rc.1
• @deepseek-ai/dsh-client-connection: 0.1.5-rc.1
• @deepseek-ai/dsh-host-webserver: 0.1.5-rc.1
• OS: Windows 11
• Node: v22.23.2
• Reproduced with third-party plugin dsh-plugin-subscriptions@0.8.0 (https://github.com/V1ki/dsh-plugin-subscriptions), which calls connection.rpc.handle('/subscriptions-auth', handler, { authority: 'loopback' }) from inside its own ctx.inject(["connection"], ctx => { ... }) callback — exactly the pattern the package's own doc comment describes as supported (register(owner, channel, handler) takes an arbitrary calling Context as owner).

This is very likely not specific to this one plugin — any plugin using the public dsh-client-connection RPC registration API from its own deferred/injected context will hit the same failure, because the bug is in HostConnectionService.register() itself, not in the third-party plugin.

Reproduction

1. Install any plugin that registers an RPC channel via ctx.inject(["connection"], (ctx) => { const connection = ctx.get("connection"); connection.rpc.handle("/my-channel", handler); }).
2. Boot dsh web normally (no special config needed).
3. Send an authenticated POST request to /my-channel/<endpoint> with a valid client-request envelope.
4. Observe: HTTP 405 instead of the plugin's actual response (200/400/401/etc.).
5. Send a GET to the same path: observe HTTP 404 — confirming the SPA static-file fallback (dsh-host-frontend-static) is answering, not the plugin's route, because the route was never registered in dsh-host-webserver's route table.

Confirmed via added diagnostics (this session)

Adding process.stderr.write(...) diagnostics directly inside dsh-client-connection's register() method showed:

register() called for channel /subscriptions-auth
webServer injected for channel /subscriptions-auth      <- the inject(["webServer"], webCtx => ...) callback DOES fire
calling webCtx.webServer.register for /subscriptions-auth
fiber REJECTED for /subscriptions-auth: Error: cannot get property "webServer" without inject
    at Fiber.<anonymous> (.../dsh-client-connection/lib/index.js:623:29)   <- webCtx.webServer.register(route) itself
    at .../cordis/lib/index.js:1141:34
    at Object.callback (.../dsh-client-connection/lib/index.js:621:18)
    at Fiber.execute (.../cordis/lib/index.js:1070:28)
    at .../cordis/lib/index.js:1141:34
    at Proxy.inject (.../cordis/lib/index.js:1600:15)
    at Proxy.register (.../dsh-client-connection/lib/index.js:619:23)
    at Object.apply (.../cordis/lib/index.js:120:36)
    at Object.handle (.../dsh-client-connection/lib/index.js:543:39)
    at Fiber.<anonymous> (.../dsh-plugin-subscriptions/lib/index.js:1456:38)

Notably: even inside the callback that ctx.inject(["webServer"], webCtx => ...) hands back (where webCtx should, by definition, carry webServer access), calling webCtx.webServer.register(route) inside a further nested webCtx.effect(...) call still throws "cannot get property webServer without inject". This suggests the failure is not simply "the wrong Context object was captured" (the originally-suspected bug — HostConnectionService.ctx never being updated to the webServer-carrying Context created at apply() time) but something about how Cordis's service-access guard interacts with inject/effect call chains that cross plugin boundaries and are nested several levels deep (subscribing plugin's effect → dsh-client-connection's register() → its own inject → its own effect).

Original (unmodified) code path, for reference:

// dsh-client-connection/lib/index.js
register(owner, channel, handler) {
  assertChannel(channel);
  const fetchHandler = rpcFetchHandler(channel, handler);
  const route = { kind: "prefix", path: channel, handler: /* ... */ };
  return owner.effect(() => owner.webServer.register(route), `client-connection: ${channel} rpc channel`);
  //                         ^^^^^^^^^^^^^^^^ throws here; `owner` (== `HostConnectionService.ctx`,
  //                         captured at construction time in apply()) was never injected with webServer.
}

// same file, apply() — the ONLY place in this file that successfully talks to webServer:
async function apply(ctx, config) {
  // ...
  const connection = new HostConnectionService(ctx, trustedHosts, /* ... */);
  ctx.inject(["webServer"], (webCtx) => {
    // ... only this webCtx (never propagated to `connection.ctx`) can reach webServer directly.
    webCtx.effect(() => webCtx.webServer.register(route), "client-connection: /api route");
  });
}

Two fix attempts tried this session (both insufficient — documenting for maintainers)

Attempt 1 — reassign connection.ctx = webCtx inside the apply()-level ctx.inject(["webServer"], ...) callback, so later calls to register() (from any plugin) see a Context that has webServer. Not fully tested before attempt 2 looked more correct; abandoned due to an inherent race (no guarantee register() is called from third-party plugins strictly after this reassignment runs).

Attempt 2 — change register() itself to defer via its own owner.inject(["webServer"], webCtx => webCtx.effect(() => webCtx.webServer.register(route), ...)), mirroring the pattern already used successfully for the /api route inside apply(). This did avoid the immediate synchronous throw (the outer ctx.inject(["connection"], ...) callback in the calling plugin no longer sees an exception), but the inner webCtx.webServer.register(route) call still throws the same "cannot get property webServer without inject" error, confirmed via fiber.then(onFulfilled, onRejected) on the returned Fiber. See stack trace above.

This means the bug is deeper than "the captured Context lacks webServer" — even a freshly-injected webCtx fails when accessed from inside a nested effect() that itself originates from a call chain crossing from a different plugin's own effect. Both attempted fixes were reverted; the shipped 0.1.5-rc.1 code is currently unmodified in this environment.

Impact

Any plugin's Settings/Subscriptions-style RPC channel (registered via the public connection.rpc.handle() API from the plugin's own injected context) silently fails to mount. The plugin appears to load without error; only a live HTTP probe reveals the channel is unreachable (405 for POST, 404 for GET). This is a functional regression for third-party plugin authors following the documented/supported registration pattern, and is likely to affect other plugins beyond the one used to reproduce it here.

Suggested areas to investigate

• Whether Cordis's service-access guard ("cannot get property ... without inject") is scoped per-Fiber rather than per-Context-object, and whether a Context returned by inject() genuinely carries a usable access grant when the code accessing it runs inside a further nested effect/inject initiated from outside the plugin that originally called inject().
• Whether HostConnectionService.register() needs to capture/refresh its Context differently, or whether dsh-client-connection needs to expose a different public API shape that plugins are expected to use instead of directly calling owner.effect(() => owner.webServer.register(route)) with an owner the plugin does not fully control the injection state of.

[Mide69]

This is the same bug already being worked through in #6227, and I think I can explain why your Attempt 2 still throws while the fix verified there does not, worth cross-checking.

Confirmed your core diagnosis against current master first: packages/client/connection/src/rpc-host.ts's rpc getter does const owner = this.ctx, and HostConnectionService is constructed with the plugin's own apply-time ctx (packages/client/connection/src/index.ts), which only declares inject = ['credentials']. Exact match.

On why Attempt 2 (owner.inject(['webServer'], webCtx => webCtx.effect(...)) called fresh, inside register()) still fails while #6227's verified fix does not: the structural difference is when the inject() call happens, not just what it looks like.

In #6227's working fix, ctx.inject(['webServer'], webCtx => { connection.webCtx = webCtx; ... }) is called exactly once, synchronously, during the connection plugin's own apply() — the same call already used for the /api route. register() never calls inject() itself; it just reads the already-captured webCtx and does (this.webCtx ?? owner).webServer.register(route) inside owner.effect(). No new inject() call happens at request time.

Your Attempt 2 calls owner.inject(['webServer'], ...) fresh, inside register(), which by the time it runs is deep inside a call chain that originated from a completely different plugin's own later, dynamic ctx.inject(['connection'], ...) callback — well after both plugins' synchronous apply() phases finished. Cordis's inject/fiber model (I read through vendor/cordis/src/reflect.ts's property guard to check this) walks a fiber's declared parent chain that's established as part of the plugin composition graph. A fresh inject() called ad hoc, long after apply(), from inside another plugin's own nested runtime callback, may not produce a fiber wired into that graph the same way a same-tick apply()-time inject() does. That would explain why the property-access guard cannot find webServer anywhere up the chain for your webCtx, even though the callback itself did fire (confirmed by your own diagnostics).

If that's right, the practical implication is: your case (calling connection.rpc.handle() from inside your own plugin's ctx.inject(['connection'], ...) callback) should actually be fixed by #6227's approach too, since that fix removes the need for register() to call inject() at all, it just reuses a webCtx that was already correctly wired during the connection plugin's own apply(). Worth trying wsxwj123's exact patch from #6227 against your repro rather than your own Attempt 2, since the two aren't equivalent despite looking similar. Might be worth linking these two threads together either way, since they're clearly the same root cause.

[TangSuann]

Update: the third-party plugin (dsh-plugin-subscriptions) that I used to reproduce this has since shipped a fix on its own side — upgrading it from 0.8.0 to the current latest 0.9.1 resolves the 405 in my environment, confirmed with a fresh restart and a live HTTP probe on /subscriptions-auth/proxyGet (was 405, now answers correctly).

Also tried applying @wsxwj123's verified patch from #6227 directly to dsh-client-connection (the attachWebContext/webCtx ?? owner approach) against my own real profile before the plugin update landed — in my environment it did not resolve the 405 (still got 405 on POST after the patch, with the patch's own code paths confirmed present and loaded). Not sure yet whether that's an environment difference or a deeper wrinkle in the fix; flagging in case it's useful data for anyone still chasing the framework-side root cause. I've since reverted that patch since the plugin-side fix is unblocking me for now.

So it looks like plugin authors following the "inject webServer yourself, then pass that context as owner" workaround (as documented in #6227) is the reliable fix from the plugin side today, whether or not the framework-side register() regression itself gets patched.