[Bug] 0.1.7-rc.1：首次切换推理档位后 sessionController 失效，后续切换失败

[hpqc032]

问题概述

在 @deepseek-ai/dsh@0.1.7-rc.1 Web 端，推理档位在进程启动后只能成功切换一次。再次切换时会报错：

gateway/service-unavailable: typert gateway: session/modelCatalog: active Service "sessionController" is unavailable

这不是会话损坏。第一次切换已经成功，并在会话日志中持久写入了 model/selection 事件。问题发生在第一次成功切换触发“全局默认模型”配置写入及配置重载之后。

复现步骤

1. 使用官方 DeepSeek 适配器启动 Web profile，默认推理档位为 high。
2. 打开一个普通会话。
3. 将推理档位从 high 切换为 low：
   • RPC 调用成功；
   • 会话日志写入 model/selection { reasoningEffort: "low" }。
4. 再次打开模型选择器，选择其他推理档位。
5. 模型目录请求失败，提示 sessionController 不可用；页面中的“重新加载”无法恢复。

重启 DSH 后服务会暂时恢复，但同样的问题会再次出现：第一次切换成功，之后的切换全部失败。

已确认的服务端调用链

SessionCommandController.selectModel() 同时执行了两件事：

this.agents.selectForNextRequest(agent, selected)
await this.ctx.agentDefaultModel.saveSelection(selected)

第一步正确地记录了会话级模型选择；第二步却通过 configEditor.edit() 改写部署级默认配置并触发整个 profile 的配置协调/重载。重载过程中 session-controller 被卸载，之后未能恢复为可用状态，所以后续的 session/modelCatalog 和模型选择请求都会失败。

在同一进程中的直接验证结果：

• 切换前：session/modelCatalog 成功；
• 执行 session/selectModel(... reasoningEffort: "low") 成功；
• 500 ms 后：session/modelCatalog 返回 gateway/service-unavailable；
• 2 秒后：仍然返回相同错误。

仅在客户端增加模型目录重试无法解决，因为服务端的 sessionController 没有恢复。

已验证的临时修复

从 selectModel 中移除部署级默认配置写入，只保留会话级选择：

this.agents.selectForNextRequest(agent, selected)
return { selected: { ...selected } }

修改后，在同一进程、同一会话中连续执行以下切换均成功，并且每次切换后 session/modelCatalog 都保持可用：

high → low → max → off → low

这也符合该方法自身的注释：“Validate and install one Session-local model selection.”

期望行为

• 在会话中切换模型或推理档位时，只修改当前会话。
• 不应静默改写部署级默认模型，也不应触发整个 profile 重载。
• 每次切换后 sessionController 都应保持可用。
• 如果用户希望修改全局默认值，应通过独立、明确的设置操作完成。

相关讨论

• Session-scoped model and effort selection #7179：Session-scoped model and effort selection。已指出 rc.1 中 agentDefaultModel.saveSelection 将会话选择与全局默认配置错误绑定。
• [UX] Session model switching should not overwrite the deployment default #3398：Session model switching should not overwrite the deployment default。记录了更早的会话选择改写全局默认设置问题。

本报告补充了 0.1.7-rc.1 中可稳定复现的具体回归：配置重载后 sessionController 持续不可用，导致模型/推理档位选择器在每次进程启动后只能成功使用一次。

环境

• DSH：0.1.7-rc.1
• Node.js：v22.23.2
• 使用界面：Web
• 操作系统：Linux
• 适配器：官方 DeepSeek（deepseek-flash）

[argszero]

Thanks for the write-up — the call chain you quoted is the whole story, and it points at a seam that a plugin can occupy. Two things I can add from reading both releases: what makes the second switch fail mechanically, and a shipped plugin that answers the offending write.

The failing write is the deployment-wide one, and it is not on the picker's per-request path

selectModel() does two unrelated things:

this.agents.selectForNextRequest(agent, selected)          // session-local — correct
await this.ctx.agentDefaultModel.saveSelection(selected)   // deployment-wide — the escalation

Only the second one is the regression. selectForNextRequest is the per-request path the method's own comment describes ("Validate and install one Session-local model selection"); saveSelection is deployment state, and in this build it reaches the profile's config document and triggers the reconcile/reload that unloads session-controller. Your timing probe is consistent with that reading: the catalog request is fine until the reload completes, and then it fails permanently — so client-side retry cannot help, exactly as you concluded.

Your local patch (drop the second call, keep the first) is the minimal fix at the call site.

Where a plugin can stand

The upstream fix belongs in core. In the meantime the seam is plugin-mountable, because the escalation is an ordinary service method on agentDefaultModel — a plugin can wrap it without touching the harness.

I published the plugin I built for this: @argszero/cordis-plugin-session-model@0.2.0.

npm i @argszero/cordis-plugin-session-model@0.2.0

Default behaviour is deploymentDefault: 'keep' — the deployment-wide write is suppressed and the session-local selection still goes through, so high → low → max → off → low works in one process. Setting deploymentDefault: 'write' disables the guard and lets the harness write reach the document (useful for A/B-ing the difference on your machine).

Two design notes that came out of building it:

• The guard answers the write line-agnostically. The body of that write moved between releases: the installed 0.1.6-alpha.2 line reaches it via settings.replace, while 0.1.7 uses configEditor.edit plus fiber.entry. A precondition that mirrored either spelling would silently disable the guard on the other line, so it does not mirror either — it guards the call, whatever the body looks like.
• The wrap lands on the underlying instance, not on ctx.get(). A read of ctx.get('agentDefaultModel') hands back a fresh traceable view each time, so the plugin resolves the raw instance through symbols.original (Symbol.for('cordis.original')) and wraps that. If you want to verify it took effect, ctx.sessionModel.deploymentDefault() reports { mode, seam, suppressed }, where seam is 'installed' | 'absent' | 'not-guarded' — the plugin reports which seam it found rather than assuming one exists.

One migration note for anyone on the 0.1.7 line

The plugin writes a durable user-role notice when it suppresses a write. On the 0.1.7 line the generic 'plugin' message source kind was removed (commit fb79a944f5 refactor(llm): separate durable producer sources from request inputs), so the notice uses a producer-owned source kind instead (source.kind: 'session-model', form: 'notice'). On the 0.1.6 line and earlier that kind does not exist, which is why the peer range is a union across lines rather than a single range.

Compatibility as I measured it — behaviour suite green on 0.1.2-rc.1, 0.1.3-alpha.2, 0.1.6-alpha.2, 0.1.7-alpha.2, 0.1.7-rc.1; the 0.1.5-* and 0.1.6-alpha.1 lines report not measurable because they no longer install from the registry at all (upstream lock-step peer drift: dsh-system-prompt@0.1.5-rc.3 peers dsh-llm@^0.1.5-rc.3 while the agent peers ^0.1.5-rc.1), which I confirmed is independent of this change by reproducing it with the plugin's pristine 0.1.0 manifest.

Finally, the expectation in your last section is the same one #3398 and #7179 already asked for: a session-scoped pick must not rewrite the deployment default. So the guard is a temporary stand-in for that semantics, not a different opinion about it — when core drops the deployment-wide write from selectModel, the plugin becomes a no-op and can be unmounted.