[Bug] dsh-client-connection@0.1.5-rc.1 fix(client-connection): register() resolves webServer without inject, breaking every rpc.handle() consumer

[bfg10knewtype]

Environment

• DSH: 0.1.5-rc.1 (npm @deepseek-ai/dsh@0.1.5-rc.1, also reproduced from a monorepo checkout of the same tag)
• OS: Windows 11, Node v24.19.0
• Plugin under test: an out-of-tree host plugin calling ctx.connection.rpc.handle(...)

Summary

HostConnectionService.register() resolves its route through owner.webServer, but the connection plugin's own static inject no longer declares webServer. Any plugin that registers a channel through ctx.connection.rpc.handle() therefore fails the whole plugin-tree load with:

Error: dsh: plugin tree failed to load: failed to apply loader entry <plugin>: 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.apply (.../cordis/lib/index.js:120:36)
    at Object.handle (.../dsh-client-connection/lib/index.js:543:39)
    at registerAutomationRpc (.../<plugin>/lib/index.js:134:29)

The failure takes down the entire Web UI — not just the offending plugin.

Root cause

In @deepseek-ai/dsh-client-connection@0.1.5-rc.1, lib/index.js:

// line 539-546 — the rpc getter hands the caller's owner to register()
get rpc() {
    const owner = this.ctx;
    return {
        handle: (channel, handler) => this.register(owner, channel, handler),
        ...
    };
}

// line 602-619
register(owner, channel, handler) {
    assertChannel(channel);
    const fetchHandler = rpcFetchHandler(channel, handler);
    const route = { kind: "prefix", path: channel, handler: async (req, res) => { ... } };
    return owner.effect(() => owner.webServer.register(route), `client-connection: ${channel} rpc channel`);
    //                    ^^^^^^^^^^^^^^^^ resolves against the connection plugin's own context
}

owner here is this.ctx — the connection plugin's own context, not the calling plugin's. Line 618 resolves owner.webServer, which requires the connection fiber to declare webServer in its inject map.

But the plugin's static declaration dropped it during this release:

// lib/index.js (0.1.5-rc.1)
const inject = ["credentials"];

Versus the previous release:

// 0.1.2 packages/client/connection/src/index.ts:67
export const inject = ['webServer', 'credentials']

The plugin now acquires webServer through a dynamic inject in apply() instead (line 758), which does not extend the plugin fiber's own inject map:

ctx.inject(["webServer"], (webCtx) => {
    ...
    webCtx.effect(() => webCtx.webServer.register(route), "client-connection: /api route");   // line 781 — correct pattern
});

So the plugin's own /api route is fine, but the public register() API — which third-party plugins call through rpc.handle() — is not.

The cordis guard that throws is reflect.ts / lib/index.js:680-694:

if (prop in fiber.inject) { error.message = `cannot get required service "${prop}" in inactive context`; throw error; }
if (!fiber.runtime) throw error;
if (fiber.parent[symbols.isolate][prop] !== key) throw error;

Because the failing fiber is the connection plugin's, adding webServer to the calling plugin's inject has no effect — which makes this bug especially confusing to diagnose from plugin side.

Why it is not caught by in-tree tests

No in-tree plugin uses connection.rpc.handle(). In-tree consumers either register exact Fetch routes (connection.fetch.register, which never touches owner.webServer) or call ctx.webServer.register() directly from a plugin that does declare the injection. This out-of-tree plugin appears to be the only rpc.handle() consumer, so the regression slipped through.

Suggested fix

Make register() resolve webServer the same way apply() already does, e.g.:

register(owner, channel, handler) {
    assertChannel(channel);
    const fetchHandler = rpcFetchHandler(channel, handler);
    const route = { kind: "prefix", path: channel, handler: async (req, res) => { ... } };
    return owner.inject(["webServer"], (webCtx) =>
        webCtx.effect(() => webCtx.webServer.register(route), `client-connection: ${channel} rpc channel`));
}

…or restore 'webServer' in the plugin's static inject if the connection plugin is meant to require the web server (note this would also change headless/SDK load behaviour, which is presumably why the dynamic inject was introduced).

Workaround for plugin authors (works on 0.1.2 and 0.1.5)

Do not let the connection plugin resolve webServer for itself. Obtain a webServer-injected child context and pass it as the owner:

let dispose: () => Promise<void> = async () => {}
ctx.inject(['webServer'], (webCtx) => {
  dispose = webCtx.connection.register(webCtx, '/my-channel', handler)
})
return async () => { await dispose() }

Verified working against both 0.1.2-rc.1 and 0.1.5-rc.1.

Reproduction

1. Install 0.1.5-rc.1.
2. Add any host plugin that calls ctx.connection.rpc.handle('/channel', handler, { authority: 'loopback' }) in apply().
3. Boot dsh web → plugin tree fails to load, Web UI never starts.

---

Related finding (same release): an undocumented breaking change

While adapting the same plugin to 0.1.5-rc.1 we hit a second breakage that does not appear in the release notes' breaking-change list (which documents only "移除 ctx.agent，调用方需显式传递 Agent").

Session.events — the public array property — was replaced by the snapshotEvents() method. Reading the old property now yields undefined, with two very different symptoms:

for (const event of session.events) { /* ... */ }        // TypeError: events is not iterable
for (const event of session.events ?? []) { /* ... */ }  // silently loops zero times

The second form is the dangerous one: nothing throws, the feature just stops producing output. In our case an auto-summarizer quietly stopped writing entries into the memory store; it was found only because a different consumer crashed on the same property.

Suggested documentation fix: list session.events → snapshotEvents() (with eventAt() / ownEvents() as the indexed-read replacements) among the 0.1.5 breaking changes.

Cross-version read that works on both releases:

const events = typeof session.snapshotEvents === 'function'
  ? session.snapshotEvents()
  : (session.events ?? [])

[wsxwj123]

Independently reproduced, and the proposed fix is verified working end-to-end.

Environment: macOS 15, Node v25.9.0, @deepseek-ai/dsh@0.1.5-rc.1 (npm latest), profile web, 169 plugin entries.

Confirmed both things you described:

• const inject = ["credentials"] in dsh-client-connection@0.1.5-rc.1, while register() resolves owner.webServer with owner === this.ctx.
• Adding webServer to the calling plugin's static inject has no effect. I tried that first (it is the obvious-looking fix) and got the identical throw — worth calling out in the report, because it sends you down the wrong path for a while.

Two data points for the report

1. The blast radius is larger than a single plugin. You noted the out-of-tree plugin appeared to be the only rpc.handle() consumer. Scanning the direct dependencies of a real profile I found 4: dsh-automation, dsh-appearance-gallery, dsh-session-manager, dsh-turn-scrubber. Because the throw is synchronous and aborts the whole plugin-tree load, only the first one in load order is ever reported — which makes this look like one plugin's problem when it is not.

2. Scope is exactly rpc.handle. connection.fetch.register goes through registerFetchRoute and never reads owner.webServer; connection.rpc.intercept goes through registerInterceptor and only touches the internal interceptor map. Neither is affected. Only handle() is.

Verified fix

Your suggested direction works. I used a variant that preserves the original effect-ownership semantics:

// apply() — reuse the webCtx already created here
ctx.inject(["webServer"], (webCtx) => {
    connection.webCtx = webCtx;
    // ...existing /api route registration unchanged
});

// register() — resolve webServer through the webServer-injected context,
// but keep owner.effect() so the route still dies with its caller
return owner.effect(
    () => (this.webCtx ?? owner).webServer.register(route),
    `client-connection: ${channel} rpc channel`
);

One detail worth keeping if you take the owner.inject([...]) route from your proposal: owner.effect(...) as the outer wrapper is what ties the route's lifetime to the calling plugin. With webCtx.effect(...) the route's lifetime follows the connection plugin instead, so a caller that unloads leaves its channel mounted. The ?? owner fallback keeps today's behaviour on profiles with no webServer (headless/tui), where throwing is arguably still the right signal.

Results after patching only dsh-client-connection

Check	Result
plugin tree load	succeeds, no error
plugin entries	141 active / 28 disabled / 0 with a load error
POST /api/pluginManager/list	{"ok":true}, full entry list returned
RPC channel reachability	/api/pluginManager/list answers 200 with a structured response; unknown endpoints 404

Reproduced on a real profile with all four rpc.handle() consumers installed and enabled — not a unit-test-only confirmation. I verified at the API level rather than through the rendered UI, so treat the "Web UI boots" half as implied by the above rather than separately measured.

[bfg10knewtype]

Thanks for the thorough reproduction and for trying the obvious-looking fix first.
Your two data points change the picture: with 4 in-profile consumers and load-order masking, this was never a single-plugin bug; and scoping it to handle() alone makes the fix much safer to reason about.
Your variant is better than my proposal — keeping owner.effect() as the outer wrapper preserves route lifetime semantics, and the ?? owner fallback keeps headless behavior intact. Would you like to open the PR with it? I'm happy to verify the patch on Windows 11 / Node v24 against a real profile if that's useful.

[wsxwj123]

Thanks @bfg10knewtype — happy to. One wrinkle worth flagging first.

deepseek-ai/deepseek-harness cannot take a pull request from here. CONTRIBUTING states that external pull requests are not accepted at the moment, and the repository has pull requests disabled outright: has_issues: false, POST /repos/deepseek-ai/deepseek-harness/pulls returns 404, and there is no Pull requests entry in the repository navigation.

So I pushed the commit to my fork and am pasting it below — please take it however is most useful:

• branch: https://github.com/wsxwj123/deepseek-harness/tree/fix/client-connection-rpc-handle-webcontext
• commit: cb9b6e2 (based on master)

diff --git a/packages/client/connection/src/index.ts b/packages/client/connection/src/index.ts
index 98a4354..f466b69 100644
--- a/packages/client/connection/src/index.ts
+++ b/packages/client/connection/src/index.ts
@@ -118,6 +118,9 @@ export async function apply(ctx: Context, config?: ConnectionConfig): Promise<vo
   )
   ctx.inject(['webServer'], (webCtx) => {
     assertImageBodyCapacity(webCtx, maxRequestBodyBytes)
+    // `rpc.handle` mounts caller-owned channels on the HTTP server; hand it the
+    // context that actually injected `webServer` (see attachWebContext).
+    connection.attachWebContext(webCtx)
     webCtx.on('webserver/index-inject', (table) => {
       table.push({ kind: 'global', name: '__DSH_CONNECTION_RECOVERY__', value: recovery })
     })
diff --git a/packages/client/connection/src/rpc-host.ts b/packages/client/connection/src/rpc-host.ts
index d74734e..bbe91f3 100644
--- a/packages/client/connection/src/rpc-host.ts
+++ b/packages/client/connection/src/rpc-host.ts
@@ -60,6 +60,11 @@ declare module '@deepseek-ai/cordis' {
 export class HostConnectionService extends Service implements HostConnectionHandle {
   private readonly interceptors = new Map<string, ConnectionRpcInterceptor>()
   private readonly fetchRoutes = new Map<string, RegisteredFetchRoute>()
+  /**
+   * The context that injected `webServer`, adopted via {@link attachWebContext}.
+   * `undefined` on deployments without an HTTP server (headless/tui).
+   */
+  private webCtx: Context | undefined
 
   /**
    * Provide the Host half over the active HTTP server.
@@ -75,6 +80,23 @@ export class HostConnectionService extends Service implements HostConnectionHand
     super(ctx, 'connection')
   }
 
+  /**
+   * Adopt the context that injected `webServer`, so channel routes can be
+   * mounted through it.
+   *
+   * `rpc.handle` receives the *caller's* Context as its owner, but a caller
+   * cannot inject `webServer` itself: the service lives on a sibling row, so
+   * property access walks only the caller's own ancestor chain and fails with
+   * `cannot get property "webServer" without inject` — which aborts the whole
+   * plugin-tree load, not just the offending plugin. The context that mounted
+   * this service is the one place that both injects `webServer` and stays alive
+   * for the process lifetime, so it is the correct resolver.
+   * @param webCtx - the `webServer`-injected context.
+   */
+  attachWebContext(webCtx: Context): void {
+    this.webCtx = webCtx
+  }
+
   /** Generic channel registry scoped to the Context reading this service. */
   get rpc(): HostConnectionRpc {
     const owner = this.ctx
@@ -175,8 +197,14 @@ export class HostConnectionService extends Service implements HostConnectionHand
         await bridge(req, res, fetchHandler)
       },
     }
+    // Resolve through the webServer-injected context, but keep `owner.effect`
+    // as the OUTER wrapper: that is what ties the route's lifetime to the
+    // calling plugin. `webCtx.effect(...)` would tie it to Connection instead,
+    // so a caller that unloads would leave its channel mounted. The `?? owner`
+    // fallback preserves today's behaviour — and its loud failure — on
+    // deployments without an HTTP server (headless/tui).
     return owner.effect(
-      () => owner.webServer.register(route),
+      () => (this.webCtx ?? owner).webServer.register(route),
       `client-connection: ${channel} rpc channel`,
     )
   }

If there is a repository where you'd like this as an actual PR — a downstream fork, a patch collection, anything — point me at it and I'll open it there.

And yes please to the Windows 11 / Node v24 run against a real profile. This is a whole-tree load failure with load-order masking, so an independent composition is exactly the evidence it deserves.

[bfg10knewtype]

Good catch on the PR gate — I'd missed that external pulls are disabled. The fork commit is a perfect home for the fix, and the diff reads clean: attachWebContext keeps the ownership semantics exactly where they belong.

Time to make good on my offer: I'll pull your branch and verify it on Windows 11 / Node v24 against the real profile where this bug originally took down my web UI, and report back here.

And credit where due — @Alkaid2333's parallel repro (#6337) found the CI blind spot (the spec injects a fake webServer), which explains how this survived to release. Between the three of us: root cause, blast radius, a verified fix, and the test gap. Thanks, both.

[Alkaid2333]

Independent repro of the same root cause, plus a same-package contrast that makes it obvious: index.ts's /api route uses ctx.inject(['webServer'], webCtx => webCtx.effect(...)), while rpc-host.ts's handle() uses the service's own this.ctx — so owner.webServer never resolves. CI blind spot also confirmed: node-half.host.spec.ts injects a fake webServer, so connection and webServer coexist in the test context and the real deployment path isn't exercised.

Write-up: #6337

[TangSuann]

Adding a cross-link and one data point: reproduced this exact issue via dsh-plugin-subscriptions (details in #6270), and can confirm the plugin author has since shipped a fix on their side (0.8.0 → 0.9.1) using what looks like the "caller injects webServer itself, passes that context as owner" workaround described above — resolved the 405 in my environment.

For what it's worth, I also tried applying @wsxwj123's verified attachWebContext/webCtx ?? owner patch directly to dsh-client-connection against my own real profile (Windows 11, Node v22.23.2, 0.1.5-rc.1) before the plugin update landed, and it did not resolve the 405 for me — same synchronous "registered OK" followed by a still-405 endpoint. Diagnostics confirmed the patched code paths were loaded and running. I don't have a clean explanation for the discrepancy with wsxwj123's verified result; could be something specific to my plugin's call shape, or a timing/ordering detail the patch doesn't fully cover. Reverted the framework patch since the plugin-side fix unblocks me for now, but wanted to leave this here in case someone continues on the framework fix — the discrepancy might be worth tracking down before this becomes the official patch.