[Windows] 设置写入与插件安装全部失败：dsh: profile reload requires the root Include entry（DSH Desktop 0.2.1-rc.2）

[jingyukong-666]

[Windows] 设置写入与插件安装全部失败：dsh: profile reload requires the root Include entry（DSH Desktop 0.2.1-rc.2）

摘要

在 DSH Desktop（0.2.1-rc.2）里，任何会触发 profile 重载的操作都会失败并回滚：

• 设置页写配置（例如把 Agent 预设设为默认值）
• 插件市场安装 / 更新插件
• 任何调用 ctx.remote.settings.update() 的插件

统一报同一条错误：

dsh: profile reload requires the root Include entry

原因不是配置写错，而是：@deepseek-ai/dsh-app-boot 在同一个进程里存在两个独立副本（一个在 app.asar 内，一个在 profile 的 node_modules 内）。Desktop 宿主用 asar 内的副本调用 boot()，该副本把 root Include 的 Entry 存进模块内私有的 WeakMap bootstrapIncludes；而改配置时被调用的是 profile 副本的 recompose()，它查自己那份 WeakMap，永远查不到。

两个副本的文件内容完全一致（SHA256 相同），差别只在模块实例。

环境

项	值
应用	@deepseek-ai/dsh-desktop 0.2.1-rc.2
Electron	44.7.0
Node	24.21.0
平台	win32 x64（Windows 10）
profile	desktop，路径 <USERPROFILE>\.dsh\profiles\desktop

复现步骤

1. 在 DSH Desktop 中打开 设置 → Agent 预设，把任一预设设为默认值。
2. 或者：在插件市场安装 / 更新任意插件。

实际行为

操作失败，界面提示重启；插件市场日志（.dsh-market/log.ndjson）记录：

{"level":"error","event":"install","detail":"dsh-image-generation@0.1.3 exit=1 err=dsh: profile reload requires the root Include entry"}
{"level":"error","event":"update","detail":"@michengai/dsh-archive-manager -> 1.1.6 exit=1 err=dsh: profile reload requires the root Include entry"}
{"level":"error","event":"update","detail":"cc-safety-net -> 2.6.16 exit=1 err=dsh: profile reload requires the root Include entry"}

预期行为

设置写入与插件安装应当直接生效，或至少给出可操作的诊断，而不是把整个写入回滚。

根因分析

1. 同一份代码被加载了两次

<安装目录>\resources\app.asar\dsh\node_modules\@deepseek-ai\dsh-app-boot\lib\index.js
<USERPROFILE>\.dsh\profiles\desktop\node_modules\@deepseek-ai\dsh-app-boot\lib\index.js

两份文件字节相同（SHA256 同为 5135179A...，此处省略完整值，可用 Get-FileHash 自行核对），但用 URL 分别 import 得到的是不同的模块对象：

const asar = await import(asarUrl);
const prof = await import(profileUrl);
asar === prof                      // false
asar.recomposeProfile === prof.recomposeProfile   // false
asar.PluginPackages === prof.PluginPackages       // false

2. Entry 存在模块私有的 WeakMap 里

dsh-app-boot 内部：

const bootstrapIncludes = new WeakMap();

async function mountRootInclude(ctx, absoluteConfigPath, patches, bareModuleBaseUrl, binName = "dsh") {
  // ...
  const includeId = await ctx.loader.create(rootInclude);   // id: "include", name: "cordis:include"
  const entry = loader.resolve(includeId);
  bootstrapIncludes.set(ctx, entry);                        // ← 只写进「调用 boot() 的那份副本」
  return entry;
}

async function recompose(ctx, patches, binName, options, withResolution) {
  const entry = bootstrapIncludes.get(ctx);                 // ← 查「当前副本」的 WeakMap
  if (entry === void 0) throw new Error(`${binName}: profile reload requires the root Include entry`);
  // ...
}

Desktop 走 asar 副本的 boot() → Entry 写进 asar 副本的 WeakMap。
dsh-hmr / dsh-plugin-manager / dsh-config-editor / dsh-agent-preset-registry 从 profile 的 node_modules 解析到 profile 副本 → 查 profile 副本的 WeakMap → 空 → 抛错。

这是同一进程内的两份独立模块状态，与插件质量、配置内容、网络均无关。

3. 调用链佐证

• dsh-hmr/lib/index.js：import { recomposeProfile } from "@deepseek-ai/dsh-app-boot"
• dsh-agent-preset-registry 的 agentPresets.select → 改 preset 走 settings 写入
• 两者都按 profile 的 node_modules 解析，即 profile 副本

影响面

• 设置页的绝大多数写入（Agent 预设默认值、模型选择等）
• 插件市场的一键安装与更新（每次都回滚）
• 任何依赖 settings.update() 的第三方插件

用户侧的观感是“这个软件每次改设置都要重启、装了插件也不生效”，且错误信息完全指向错误方向。

临时规避（已验证）

root Include 的 Entry 本身在同进程的 loader 里可查——mountRootInclude() 用固定 id include 创建它。所以在 profile 副本的 recompose() 前加一步认领即可：

function adoptRootInclude(ctx) {
  const known = bootstrapIncludes.get(ctx);
  if (known !== undefined) return known;
  const loader = ctx.get("loader");
  if (loader === undefined) return undefined;
  let entry;
  try { entry = loader.resolve("include"); } catch { return undefined; }
  if (entry === undefined || entry.options?.name !== "cordis:include") return undefined;
  bootstrapIncludes.set(ctx, entry);   // 之后走正常路径
  return entry;
}

async function recompose(ctx, patches, binName, options, withResolution) {
  // const entry = bootstrapIncludes.get(ctx);
  const entry = adoptRootInclude(ctx);
  // 其余不变
}

验证结果：

• 语法正常，导出数量不变（59 个）
• 用一个「root Include 存在但本副本 WeakMap 为空」的假 ctx 调用 reconcileProfilePatches()，能越过原来的报错点继续执行
• 对照：没有 loader 的 ctx 仍原样抛出 dsh: profile reload requires the root Include entry（不会静默吞掉真故障）

这是绕过方案，不是修复：改动位于 node_modules，插件市场重装或应用升级后被覆盖。

建议的上游修法

任选其一，均为小改动：

1. 把 Entry 存在 ctx 上而不是模块闭包里：用 Symbol.for() 或 ctx.effect/ctx.set 之类的进程级共享槽位，避免依赖模块实例身份。
2. 提供按 id 兜底：recompose() 在 WeakMap 未命中时，回退到 ctx.loader.resolve("include") 并校验 options.name === "cordis:include"（即上面的规避方案）。
3. 消除双副本：Desktop 启动时把 profile 的 @deepseek-ai/dsh-app-boot 指向 asar 内副本（package.json 里 imports/overrides，或在 Loader 的 import() 里做一次 URL 归一化），让全进程只存在一个模块实例。

代价最低、风险最小的是第 2 种：只影响失败路径，命中 WeakMap 时行为完全不变。

---

English summary

Symptom. On DSH Desktop 0.2.1-rc.2 (Windows), every operation that triggers a profile reload fails and is rolled back with:

dsh: profile reload requires the root Include entry

This covers settings writes (e.g. setting the default Agent preset), plugin-market installs and updates, and any third-party plugin calling settings.update().

Root cause. @deepseek-ai/dsh-app-boot is loaded twice in one process: once from app.asar (used by the Desktop host's boot()) and once from the profile's node_modules (used by dsh-hmr, dsh-plugin-manager, dsh-config-editor, dsh-agent-preset-registry). The two files are byte-identical (same SHA256) but are distinct module instances. mountRootInclude() stores the root Include entry in a module-private WeakMap named bootstrapIncludes; recompose() reads that same private WeakMap. The host writes to the asar copy's WeakMap; the profile-side participants read the profile copy's, get undefined, and throw.

Evidence.

asar === profileCopy                                  // false
asar.recomposeProfile === profileCopy.recomposeProfile // false
asar.PluginPackages === profileCopy.PluginPackages     // false

Call sites confirming the profile-side resolution: dsh-hmr/lib/index.js imports recomposeProfile from @deepseek-ai/dsh-app-boot; agentPresets.select triggers the settings write path.

Workaround (verified). The entry is still reachable by id, because mountRootInclude() creates it under the well-known id include with name: "cordis:include". Resolving it before the WeakMap lookup lets the normal path proceed:

function adoptRootInclude(ctx) {
  const known = bootstrapIncludes.get(ctx);
  if (known !== undefined) return known;
  const loader = ctx.get("loader");
  if (loader === undefined) return undefined;
  let entry;
  try { entry = loader.resolve("include"); } catch { return undefined; }
  if (entry === undefined || entry.options?.name !== "cordis:include") return undefined;
  bootstrapIncludes.set(ctx, entry);
  return entry;
}

Validated: module still imports cleanly with the same 59 exports; a context that has a root Include but an empty local WeakMap passes the gate; a context with no loader still throws the original diagnostic (no silent masking).

Suggested fix (pick one).

1. Store the entry on the ctx via a process-wide shared slot instead of a module-local closure.
2. Fall back to ctx.loader.resolve("include") on a WeakMap miss, validating options.name (the workaround above; smallest blast radius — only the failure path changes).
3. Deduplicate the module: make the profile resolve @deepseek-ai/dsh-app-boot to the copy inside app.asar so only one instance exists per process.

[VitorRodi]

Excellent root-cause analysis. The distinction between identical package contents and separate ESM module instances is particularly important here.

I agree that recovering the root Include entry through the existing loader is a reasonable minimal fix, given the current architecture.

One addition I would suggest before merging this upstream is a regression test covering module-instance isolation explicitly.

The test should reproduce the actual failure condition:

1. Initialize the application using module instance A.
2. Ensure the root Include entry is registered in the shared loader.
3. Invoke profile recomposition through module instance B, which has a separate module-level WeakMap.
4. Verify that the fallback successfully resolves the existing root Include.
5. Verify that recomposition continues without creating a second root Include entry.

I would also add three negative tests:

• The loader is unavailable.
• The Include entry does not exist.
• An entry with the expected ID exists but its name is not cordis:include.

These cases should preserve the original failure behavior rather than silently accepting an invalid runtime state.

One subtle point: checking only the entry ID and name may not be sufficient if a loader can contain entries associated with different contexts or lifecycles. If the API exposes an ownership or parent-context relationship, validating it would reduce the risk of adopting an unrelated entry.

For the longer term, I would also consider eliminating the module-local WeakMap as the authoritative source of this state. If the loader already owns the root Include entry, making the loader the single source of truth could prevent similar bugs when package duplication occurs through Electron bundling, pnpm dependency layouts, or plugin isolation.

Your workaround appears well suited for a targeted regression test because it reproduces the original failure without requiring a complete Desktop installation.

Would you be able to turn the two-module reproduction into an automated test? That would help ensure future packaging changes don't reintroduce the same issue.