dsh-client-connection 0.1.5-rc.x: rpc.handle() broken for all callers — cannot get property "webServer" without inject

[btboys]

Summary

In dsh-client-connection 0.1.5-rc.x (verified on 0.1.5-rc.2), connection.rpc.handle(channel, handler) throws cannot get property "webServer" without inject for every caller, so any third-party plugin that registers a dedicated RPC channel fails to boot. Declaring inject: ['webServer'] in the calling plugin does not help.

This worked in 0.1.2-rc.1 and broke in 0.1.5-rc.x.

Root cause

0.1.5-rc.x narrowed the connection plugin's own inject from ["webServer", "credentials"] to ["credentials"], mounting only its own /api route inside a soft ctx.inject(["webServer"], ...) child fiber:

// 0.1.5-rc.2, lib/index.js
const inject = ["credentials"];
...
ctx.inject(["webServer"], (webCtx) => {
  ...
  webCtx.effect(() => webCtx.webServer.register(route), "client-connection: /api route");
});

But HostConnectionService.register() — the path behind rpc.handle() used by third-party channels — still does:

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

Cordis resolves service property access in the service's own fiber scope (the shadow/receiver mechanism): owner here is the ctx captured by get rpc() (this.ctx), and owner.webServer is resolved against the client-connection fiber — which no longer injects webServer. The fiber walk climbs to the root fiber and throws cannot get property "webServer" without inject.

Because the lookup happens in the connection plugin's scope, nothing on the caller side (including inject: ['connection', 'webServer']) can satisfy it. Empirically:

caller inject	0.1.2-rc.1	0.1.5-rc.2
['connection']	✅	❌ throws
['connection', 'webServer']	✅	❌ throws
ctx.inject(['connection','webServer'], c => c.connection.rpc.handle(...))	✅	❌ throws

Reproduction

Minimal cordis-level repro (cordis 4.0.2 + dsh-client-connection 0.1.5-rc.2):

import { Context, Service } from '@deepseek-ai/cordis'

const app = new Context()

class WebServer extends Service {
  static provide = 'webServer'
  register(route) { return () => {} }
}
app.plugin(WebServer)

// load the real client-connection plugin (0.1.5-rc.2), then any caller:
function caller(ctx) {
  ctx.connection.rpc.handle('/my-channel', async () => ({ ok: true, value: null }))
}
caller.inject = ['connection', 'webServer']
app.plugin(caller)
// => Error: cannot get property "webServer" without inject

Real-world impact: community plugins registering settings-page RPC channels (dsh-pocket, dsh-notify-plugin, dsh-advisors) all crash the web profile boot:

Error: failed to apply loader entry advisors (dsh-advisors): cannot get property "webServer" without inject
    at Fiber.<anonymous> (.../dsh-client-connection/lib/index.js:618:35)
    at Proxy.register (.../dsh-client-connection/lib/index.js:618:16)
    at Object.handle (.../dsh-client-connection/lib/index.js:543:39)

Suggested fix

register() should not resolve webServer through owner. Mount channel routes through the connection plugin's own soft-injected webServer scope, e.g. queue channel registrations and flush them inside the existing ctx.inject(["webServer"], webCtx => ...) block (which also fixes ordering for registrations that happen before/after webServer appears), keeping owner.effect(...) only for disposal bookkeeping:

register(owner, channel, handler) {
  assertChannel(channel);
  const route = { kind: "prefix", path: channel, handler: /* ... */ };
  return owner.effect(() => {
    let dispose;
    this.ctx.inject(["webServer"], (webCtx) => {
      dispose = webCtx.webServer.register(route);
    });
    return () => dispose?.();
  }, `client-connection: ${channel} rpc channel`);
}

(Or collect pending routes on the service and have the existing webCtx block register/unregister them.)

Workaround used by affected plugins meanwhile

Register the prefix route directly on webServer from the plugin's own fiber — ctx.inject(['connection', 'webServer'], c => c.effect(() => c.webServer.register(route))) — keeping connection.requestRejection(req) as the auth fence and replicating the client-request/server-response envelope bridge. This boots on both 0.1.2 and 0.1.5, but every plugin has to duplicate the envelope logic, so a core fix is still needed.

[PerryLink]

Confirmed 1:1 on master (c291e79), including the regression bisect:

• client-connection now injects only ['credentials'] (packages/client/connection/src/index.ts:69).
• rpc.handle closes over this.ctx (rpc-host.ts:79-86) and register() resolves owner.webServer.register(route) inside an effect with no guard (rpc-host.ts:158-182, the call at :178-181). Without webServer in the inject list, every third-party rpc.handle() caller dies exactly as you describe. Caller-side inject can't fix it — the resolution happens on the host's context.
• Regression confirmed by tag: dsh-v0.1.2-rc.1 has export const inject = ['webServer', 'credentials']; dsh-v0.1.5-rc.2 has ['credentials'].
• Scope: only rpc.handle is affected — fetch.register and intercept never touch webServer (rpc-host.ts:139-156, :184-206).

Fix direction: mirror the soft-injection pattern this same plugin already uses for its /api route (connection/src/index.ts:119-139) — resolve webServer through a soft inject (the plugin itself soft-injects webServer for index-inject, see the ctx.inject(['webServer'], ...) call in the rc.2 file) inside the effect instead of hard-injecting. master still has the bug as of c291e79; this is a good small PR target. (I verified by source + tags, not by running your repro.)