Web UI 增删模型 provider 必失败：dsh: profile reload requires the root Include entry（0.2.1-rc.2）

[HermanChen]

环境

• dsh 0.2.1-rc.2（npm @deepseek-ai/dsh，用户级前缀安装）
• Linux（kernel 5.4），Node v22.23.2
• profile：web，启动命令 dsh web --no-open --host 127.0.0.1 --port 19387 --trusted-host 10.10.10.105:19388
• 用法：本机回环监听 + socat 转发到局域网地址供浏览器访问（反向代理/端口转发场景）
• 从 0.2.0-rc.1 升级到 0.2.1-rc.2 后复现

现象

在 Web 界面「设置 → 模型」里删除（或新增）一个 provider，确认后弹窗报错：

dsh: profile reload requires the root Include entry

操作没有落盘：~/.dsh/profiles/web/cordis.patch.yml 的修改时间保持不变，等于 UI 操作是空操作，只留一条难以理解的报错。

复现步骤

1. 启动 web profile：dsh web --no-open --host 127.0.0.1 --port 19387
2. 在 profile 的用户补丁层 cordis.patch.yml 的 llm-pi-ai → config.providers 下配置至少一个 provider
3. 浏览器打开界面 → 设置 → 模型 → 删除该 provider → 确认

期望：provider 被移除并热重载。
实际：报 profile reload requires the root Include entry，配置文件无任何变化。

根因分析（阅读随包源码）

@deepseek-ai/dsh-app-boot 的 recompose()：

const entry = bootstrapIncludes.get(ctx);
if (entry === void 0)
  throw new Error(`${binName}: profile reload requires the root Include entry`);

bootstrapIncludes 是模块私有的 WeakMap，只在创建根 cordis:include 条目的引导函数里写入：

const rootInclude = {
  id: "include",
  name: "cordis:include",
  config: { path: pathToFileURL(absoluteConfigPath).href, ... },
};
const includeId = await ctx.loader.create(rootInclude);
const entry = loader.resolve(includeId);
bootstrapIncludes.set(ctx, entry);

从 Web UI 触发的 profile 重载，其运行上下文在这个 WeakMap 里查不到条目，因此在写入任何配置之前就抛错。推测是 dsh web 的启动路径没有走上述引导函数，或者 UI 编辑所用的 ctx 与登记时的不是同一个。

临时绕行（已验证可用）

绕过 UI，直接改补丁层后重启宿主：

$EDITOR ~/.dsh/profiles/web/cordis.patch.yml   # 删掉目标 provider 整块
dsh --profile web --dump-config >/dev/null     # 校验配置可解析
systemctl --user restart dsh-web               # 重启实例

建议

• 界面直接展示真实原因，而不是裸 Error 文本；
• 让所有启动路径都登记根 include，使热重载可用；或在重载不可用时禁用相关编辑入口。

---

[PerryLink]

定位是对的，但我想把"web 启动路径查不到条目"这句话换成更准确的机制：这不是哪个启动路径漏写了一次，而是这个表的键就是那个 Context 对象本身。

packages/boot/app-boot/src/index.ts:261：

const bootstrapIncludes = new WeakMap<Context, Entry>()

:336-337 取不到就抛你看到的那句；而整个仓库里唯一的写入是 :784-789——启动时创建根 cordis:include 条目的那一处，用的是传进引导函数的那个 ctx。

WeakMap 的键是对象身份。任何用别的 context 调进来的重载都会 miss：ctx.fork() 出来的子上下文、某个请求级上下文、插件自己的 ctx，全都 miss。所以它是确定性必现，不是竞态，也不取决于 web 的启动参数。

抛点也确实在任何补丁写入之前：recompose 从 :328 开始，:336 取 entry，:337 就抛。这和你观察到的 cordis.patch.yml 修改时间不变完全一致——不是"写了但没生效"，是根本没走到写。

修法我建议不要继续用 ctx 当键。根 Include 的 id 是固定的 'include'，:769-771 的注释专门说明这个 id 固定是为了让 Loader 的失败链在多次运行间稳定，所以它本身就是个可用的查找键：

const entry = bootstrapIncludes.get(ctx)
  ?? ctx.loader.entries().find(row => row.options?.id === 'include')

或者更干净一点，把 entry 挂在 loader 上而不是挂在某个 ctx 上，让"根 Include 是谁"成为进程级事实而不是上下文级事实。

一条边界：我没有你的 profile 和那台机器，无法证明 web 那次重载传进去的到底是哪个 ctx。我能确认的是键是对象身份、写入只有一处、抛点在写盘之前。这三点已经足以说明"同一个进程里换个 ctx 调用就必失败"，也足以解释为什么这件事和 provider 配置本身无关。

[HermanChen]

那要如何简洁优雅地解决这个问题？

[ltxhhz]

运行 where.exe dsh 看看盘符是不是小写，如果是的话在环境变量里改成大写，我是这么解决的
Run where.exe dsh and check if the drive letter is lowercase. If it is, update it to uppercase in the PATH environment variable.
This is how I resolved it.

[HermanChen]

我 dsh-web 运行环境是在 ubuntu 上的，路径是~/.npm-global/bin/dsh

[ltxhhz]

不好意思没看到系统信息，不过你可以检查一下是不是符号链接或者路径里~被解析的原因导致同一个实例不同路径

[HermanChen]

@ltxhhz 确认问题解决，问题原因在下面这里
#11853 (comment)

[ltxhhz]

看到了，非常感谢跟进