[Bug] Live profile reload leaves session-scoped services unavailable: session/follow fails with gateway/service-unavailable

[pridurok-goxa]

Environment

• DeepSeek Harness 0.2.0-rc.2 (@deepseek-ai/dsh), Node.js v22.23.3, Linux x64
• Profile: web (dsh web), long-running service (process uptime ~29 h at the time)
• Trigger: installing a local plugin bundle from the Plugins page in the Web GUI, so dsh.profile.bundles changes while the process is live

Summary

Installing a bundle into the running Web server left the process half-alive: the shell kept loading, but every client call into a session-scoped service failed.

Failed to load history: typert gateway: session/follow: active Service "sessionController" is unavailable (gateway/service-unavailable)

dsh-api-gateway/lib/index.js raises this in prepareInvocation():

const receiverContext = await this.resolveReceiverContext(descriptor, request.args, endpoint)
const receiver = receiverContext.get(descriptor.service)
if (!isObject(receiver)) throw new TypertGatewayError("gateway/service-unavailable", endpoint, `active Service ${JSON.stringify(descriptor.service)} is unavailable`)

The RPC reaches the gateway and the descriptor resolves, but the service instance is not registered on the resolved receiver context. Reloading the page does not help — the broken state lives in the server process, and only a process restart clears it.

Steps to reproduce

1. Start dsh web with a profile whose bundle stack enables HMR. The shipped web profile does: the hmr entry comes from @deepseek-ai/dsh-base (root: []) and stays enabled while the launcher supplies profileContext.
2. Install a plugin bundle from the Plugins page. The plugin manager rewrites package.json / pnpm-lock.yaml and, because hmr is present, applies the change in-process (dsh-plugin-manager → reload() → reconcileProfilePatches(root, readProfilePatches(...), "dsh", requiredIds)).
3. Reload the Web GUI. Session history fails with the error above; client plugins that talk to a session-scoped service stop working too.

Observed once, after installing a bundle that declares a new agent preset (@deepseek-ai/dsh-agent-preset with a nested plugins: list) and overrides session-query-sqlite. I could not re-run it on demand, because after the failure the bundle was already in the profile.

Expected

One of these, not a partial tree:

• Live profile reconciliation is atomic: if the recomposed tree fails to load, or a service that existed before is missing after it, the previous tree must be restored (and the change reported as failed); or
• Bundles are never applied to a live process: report application: "restart-required" (exactly what already happens when hmr is absent) and leave the running tree untouched.

Partial application is the worst case: the HTTP shell stays up, so the UI looks alive while session-scoped services are silently gone.

Workaround in use

Disable HMR in the profile so profile changes always require a restart:

- id: hmr
  disabled: true

With that, plugin-manager.change() returns application: "restart-required" (see dsh-plugin-manager/lib/index.js), the live tree is never touched, and an explicit restart applies the new profile — which matches the documented intent in @deepseek-ai/dsh-hmr/README.md: "Disabling or omitting HMR applies changes on restart."

Related asymmetry worth a look: when hmr is absent, removing/disabling an already-started bundle throws stop-profile (same file, the restart-required fallback path), so the removal path refuses to touch a live tree. The install path should be equally strict.

Evidence

• After the failure, dsh --profile web --dump-config still composed the tree successfully (exit 0) and the tree still contained session-controller (@deepseek-ai/dsh-api-session-controller) — the profile files were fine, only the running process was broken.
• Restarting the service fixed it: the same session/follow call over /api/remote.mux then returned a normal snapshot frame, and other client plugins recovered.

[yoklynan]

您好，请问我这个是啥原因？该如何解决？谢谢您！以前的对话是有的，但是开启不了新对话