Web bundle should declare modules -> webServer activation dependency

[ysr666]

Summary

The Web bundle should make the existing modules Loader row explicitly depend on webServer during activation.

Today the official Web composition owns both rows, but modules is still declared without an activation dependency:

- id: modules
  name: '@deepseek-ai/dsh-client-modules'

Under parallel Loader activation, adding an extra client bundle can make the Node half of @deepseek-ai/dsh-client-modules activate before webServer is available and hit the Cordis service-access race (webServer without inject). We reproduced this downstream in dsh-vision-router on the preview Host.

Proposed upstream change

Keep ownership in the Web bundle and add only the activation edge that the Web composition already requires:

- id: modules
  name: '@deepseek-ai/dsh-client-modules'
  inject: [webServer]

I would prefer this to remain Web-surface-specific rather than becoming a package-global/static dependency, because the dependency is about this bundle's activation order.

Why this is the correct seam

I traced the path end-to-end: Loader merges a row's entry.options.inject into the Cordis plugin fiber dependency map, and Cordis keeps that fiber pending until the required service is available. This is therefore a real activation dependency, not just client-graph metadata such as dsh.client.inject.

The downstream workaround currently used by Vision Router is an id-targeted, non-insert overlay:

- id: modules
  name: '@deepseek-ai/dsh-client-modules'
  inject: [webServer]

The name here is only a fail-closed identity assertion for the existing Host row. It is not intended to claim ownership of an @deepseek-ai/* component.

That workaround should not become permanent: if the official row later gains another inject dependency, a downstream field override could otherwise replace the new list. The long-term owner of this edge should therefore be the official Web bundle.

Prepared implementation

I prepared and validated the minimal upstream patch on a fork:

• Commit: ysr666@0780921
• Compare: master...ysr666:deepseek-harness:fix/web-modules-webserver-activation

The patch:

1. adds inject: [webServer] to the official Web modules row;
2. adds a regression test using DSH's own loadOverlayPatches() + composeEntries() path.

Validation

Validated against upstream master@b2e3b2a0125854567a4a5fcba75782e42fe84901 / dsh 0.1.5-alpha.2:

• packages/bundle/web-app/tests: 22/22 pass
• pnpm verify-cordis-config: 143 config files pass
• pnpm exec tsc -b packages/bundle/web-app/tsconfig.json: pass
• Oxlint: 0 warnings/errors
• upstream pre-commit hooks: pass
• upstream pre-push full pnpm run typecheck: pass

On the Vision Router side, the compatibility overlay is intentionally still present while affected DSH versions remain supported. A new lifecycle sentinel now classifies the Host state as shim-required, retire-ready, or dangerous-drift; once an official DSH release owns modules -> webServer, downstream CI will explicitly require retiring the workaround instead of silently carrying it forever.

Relevant downstream tracker: ysr666/dsh-vision-router#448

If this direction matches the intended Web bundle ownership model, the fork commit above is ready to cherry-pick or reimplement upstream.

[y0shua1ee]

Confirmed on a source checkout of master at aa8262ec091698bae9a6b04773a6b5b06ad4aef2 (0.1.5-rc.1). Following the README's source-run workflow reaches the same failure at pnpm dsh web after the build succeeds.

Environment and reproduction

• macOS 27.0 (26A428), Apple Silicon
• Node.js v24.11.0; pnpm 11.7.0
• Official repository source checkout, shipped web profile

git clone https://github.com/deepseek-ai/deepseek-harness.git
cd deepseek-harness
pnpm install
DEVELOPER_DIR=/Library/Developer/CommandLineTools pnpm run build
pnpm dsh web

The DEVELOPER_DIR override resolves a separate local Xcode/SDK linker mismatch; the build succeeds with it. The subsequent Web startup fails with:

Error: dsh: plugin tree failed to load: failed to apply loader entry include (cordis:include): failed to apply loader entry modules (@deepseek-ai/dsh-client-modules): cannot get property "webServer" without inject
Error: cannot get property "webServer" without inject
    at .../packages/client/modules/src/index.ts:572:22
    at registerWebCarrier (.../packages/client/modules/src/index.ts:571:14)
    at new ClientModuleRegistry (.../packages/client/modules/src/index.ts:577:10)

Additional diagnostic detail

The stack identifies the already-present service branch, rather than only a missing-service activation-order problem:

if (ctx.get('webServer') === undefined) ctx.inject(['webServer'], registerWebCarrier)
else registerWebCarrier(ctx)

ClientModuleRegistry declares only static inject = ['loader']. In the else branch, registerWebCarrier(ctx) reads webCtx.webServer without that injection, which Cordis rejects. See the constructor at the reproduced commit.

Verified workaround

A temporary Web-only overlay:

- id: modules
  inject: [webServer]

Starting with that overlay succeeds:

pnpm dsh web --patch /path/to/web.patch.yml --no-open --port 0

Observed results: the process prints its local startup URL; fetching that URL with cookie handling returns HTTP 200, and the HTML contains both __DSH_BOOT__ and __ModuleLoader__. The verification process was then stopped. This verifies startup and the initial HTML response, not browser interaction or a model conversation.

The overlay was tested without editing repository source. Keeping any required dependency specific to the Web composition also preserves the package's optional Web-server support for other carriers.

[Start-Gao]

This looks like it also explains a startup-time regression, so cross-linking: #6391
ClientModuleRegistry's static inject went from ['webServer','loader'] to ['loader'] in commit 1944490 ("feat: electron 打包", first shipped in 0.1.5-alpha.1). That removal also deleted an accidental deferral: the registry used to be constructed only after webServer existed — i.e. after the Loader's activation waves — so the whole client graph was composed once. It is now constructed as soon as loader exists, and every subsequent activation triggers a synchronous full recomposition (measured 1 → 8 runs; time-to-URL 2.69s → 17.3s; reverting only client-modules/lib/index.js on the current tree: 17.3s → 4.28s).
Your proposed activation edge on the Web bundle's modules row (inject: [webServer]) should restore the late construction and therefore likely fixes the startup cost as well — worth measuring both effects together.

Boundary (added after the discussion in #6391): this edge is Web-composition-only and must not be lifted into the package — the desktop host has no webServer service (apps/desktop-host/src/index.ts:302-306 requires only connection/typertGateway/clientModules, and serves /plugins/ via ctx.clientModules.fetchBundle at :200). So it can remove the Web startup cost, but it is not the root fix for it; the root fix is to let the registry's initial scan wait for activation to settle (see #6391).

[Start-Gao]

Boundary correction to my earlier comment (raised by @argszero in #6391): this edge is Web-composition-only and must not be lifted into the package.

The desktop host has no webServer service at all — apps/desktop-host/src/index.ts:302-306 requires only connection / typertGateway / clientModules, and the shell carrier serves /plugins/ through ctx.clientModules.fetchBundle(request) (:200). So adding the edge here does fix the Web startup cost (it restores the late construction → 1–2 compositions instead of 8), but it is not a root fix: the registry must keep working with no Web carrier, which is exactly what the ctx.get('webServer') === undefined branch in 19444907 exists for.

For the root fix the registry's initial scan should wait for activation to settle (e.g. the loader.await() precedent at packages/api/gateway/src/client/index.ts:177) while the not-ready window answers explicitly instead of 404-ing bundles.

[Robin1987China]

你的方向对了一半，但结论可以更省事 —— 我把两个都验了。

修复点其实在 connection 行，不是 modules。 因为抛错的是服务自己的 ctx：

const owner = this.ctx;                                   // :541
  handle: (channel, handler) => this.register(owner, channel, handler),
  return owner.effect(() => owner.webServer.register(route), ...);   // :618

它读 owner.webServer，而该行只声明 inject: [webRuntime] —— 所以是必然抛错，不是并行激活的时序问题。（我之前也怀疑是竞态，实测下来不是：同一版本每次必抛。）

顺带一个对你有用的机制细节：patch 不只能替换 config。看 dsh-app-boot/lib/index.js:102：

for (const [key, value] of Object.entries(overrides)) {
  if (key === "id") continue;
  target[key] = value;        // inject 也能这样打进去
}

所以不需要改官方 bundle 源码，一行补丁就够：

- id: connection
  inject: [webRuntime, webServer]

验证：修复前插件 rpc.handle() 抛 cannot get property "webServer" without inject、通道 POST /lab-probe 返 405；修复后不抛、返 401（已注册）。

已打包为组合包（并验证过 bundle 形态交付同样有效）：dsh-connection-rpc-fix。