[Bug] dsh-hmr: 热重载后 apply() 定时器永久携带 executing=true，导致 runExclusive 嵌套报错

[lingluochengni918]

⚠️ 2026-10-27 更新：本文原推荐的方案 A / C 已撤回——实测反证见下方评论区（方案 A 会把队列永久卡死，方案 C 缺失效机制）。修法以 @Muguett-DBY 提出的状态对象方案为准，对照实测见我的回复。正文保留原样，供追溯讨论脉络。

自己用DSH许愿写的插件，热插拔更新后一直跳出“HMR transactions cannot be nested”的刷屏信息，查找了一下原因，说是DSH内核中的一个固有问题，发上来报告一下。

dsh-hmr：插件热重载后，apply() 里注册的定时器永久携带 executing=true，导致该插件后续任何 runExclusive 调用被误判为嵌套事务

提交目标：https://github.com/deepseek-ai/deepseek-harness/issues
组件：@deepseek-ai/dsh-hmr（packages/boot/hmr）
核实日期：2026-10-26

---

TL;DR

Hmr#runExclusive() 用 AsyncLocalStorage 标记「事务进行中」，但没有在进入事务前剥掉调用方残留的上下文。
插件通过 HMR 热重载时，apply() 是在 runExclusive 事务里被调用的；此时 apply() 里注册的 setInterval / setTimeout
会把这个事务标记捕获并永久带着——事务结束后定时器仍在跳，其回调里的任何 hmr.runExclusive() 调用都会被自己的嵌套检查拒绝，
直到进程重启都无法自愈。

表现为：该插件所有需要写配置的能力（configEditor.edit()、agentDefaultModel.saveSelection() 等）静默失效，并每周期打印一条错误。

---

环境

项	值
@deepseek-ai/dsh	0.2.1-rc.2（npm latest）
@deepseek-ai/dsh-hmr	0.2.1-rc.2 / 0.2.1-rc.3（均已核实受影响）
Node.js	v24.16.0
操作系统	Windows 11

已确认 rc.3 未修复：@deepseek-ai/dsh-hmr@0.2.1-rc.3 的 lib/index.js:752-760 与本机 rc.2 的 runExclusive
实现逐字相同，缺陷依然存在。

---

复现步骤

1. 写一个插件，在 apply() 里注册定时器，并在回调里做需要配置写入的操作：

   export function apply(ctx) {
     ctx.interval(async () => {
       // 任何走到 hmr.runExclusive 的调用：
       //   ctx.configEditor.edit(...)
       //   ctx.agentDefaultModel.saveSelection({ provider, model })
     }, 15000)
   }

2. 冷启动 DSH → 一切正常。回调和事务里 hmr.executing.getStore() 为 undefined。

3. 用 HMR 热重载该插件（改文件触发 watcher / profile patch 的 disabled: true → 撤销 / 插件管理 off-on）。

4. 从此刻起，每一次定时器回调里 hmr.executing.getStore() 都是 true。

5. 回调中任何走到 hmr.runExclusive() 的调用都会被 dsh-hmr/lib/index.js:753 拒绝：

   Error: HMR transactions cannot be nested
   

6. 该状态持续到进程重启，无法自愈。

最小复现脚本

不依赖 DSH，用 AsyncLocalStorage + setInterval 复刻 runExclusive 语义：

// repro.cjs  ——  node repro.cjs cold  |  node repro.cjs hot
'use strict'
const { AsyncLocalStorage } = require('async_hooks')
const als = new AsyncLocalStorage()

// 等价于 dsh-hmr 的 runExclusive
function runExclusive(operation) {
  if (als.getStore()) return Promise.reject(new Error('HMR transactions cannot be nested'))
  return new Promise((resolve, reject) => {
    als.run(true, () => Promise.resolve().then(operation).then(resolve, reject))
  })
}

// 等价于插件的 apply()：在 start 里注册心跳
let heartbeats = 0, nested = 0
function pluginApply() {
  setInterval(() => {
    heartbeats++
    runExclusive(() => {}).catch((e) => { nested++; console.log('[plugin] 心跳内开事务失败:', e.message) })
  }, 300)
}

// cold = 冷启动（干净上下文）；hot = HMR 在事务内重启插件
if ((process.argv[2] || 'hot') === 'cold') pluginApply()
else runExclusive(pluginApply)

setTimeout(() => {
  console.log(`\n[${process.argv[2] || 'hot'}] 心跳次数=${heartbeats} 其中被「嵌套事务」拒绝=${nested}`)
  runExclusive(() => {}).then(() => console.log('事务外调用 runExclusive：成功'))
  setTimeout(() => process.exit(0), 200)
}, 1000)

实测输出

[cold] 心跳次数=3 其中被「嵌套事务」拒绝=0      ← 冷启动：正常
[cold] 事务外调用 runExclusive：成功

[plugin] 心跳内开事务失败: HMR transactions cannot be nested
[plugin] 心跳内开事务失败: HMR transactions cannot be nested
[plugin] 心跳内开事务失败: HMR transactions cannot be nested

[hot] 心跳次数=3 其中被「嵌套事务」拒绝=3       ← 热重载后：全灭
[hot] 事务外调用 runExclusive：成功             ← 证明事务外没问题，是上下文被钉住了

同一份插件代码，冷启动 0 次失败，热重载后 100% 失败。

---

根因

dsh-hmr/lib/index.js：

// :740
executing = new AsyncLocalStorage()

// :752-760
runExclusive(operation) {
  if (this.executing.getStore())
    return Promise.reject(new Error('HMR transactions cannot be nested'))   // ← :753 被自己拒绝
  const task = this.operations.then(async () => {
    if (this.closing) throw new Error('HMR is disposed')
    return this.executing.run(true, operation)                              // ← :756
  })
  this.operations = task.catch(() => {})
  return task
}

污染链条：

1. 文件变化 → watcher 的 dispatch() 在 runExclusive 内执行（:895）；
2. 其中 partialReload() 的 reload()（:1098-1126，调用点在 :1123）在同一个事务上下文里
   await fiber.await() 激活插件 fiber，于是插件的 apply() 在事务上下文里执行；
3. apply() 里 ctx.interval() / ctx.timeout() 内部是 setInterval / setTimeout。
   Node 的 AsyncLocalStorage 会被定时器钉在注册点所在的上下文——此后每一次回调都沿用该上下文；
4. 事务几毫秒后结束，但那颗定时器仍在跳、且永远带着 executing=true；
5. 回调里 saveSelection() → configEditor.edit() → hmr.runExclusive()（dsh-config-editor/lib/index.js:134）
   在第 753 行被判定为「事务里再开事务」而拒绝。

注意这不是 setInterval 的 bug，是 Node 的既定语义。问题在于 runExclusive 只防了「重入」，
没防「调用方本身带着一个陈旧的事务标记」。

一个内部佐证

同一文件 :776 的 watchConfig 里，团队已经显式剥离过上下文：

const dispose = await this.executing.exit(() => watchConfig(...))

说明「ALS 上下文需要显式清理」这个语义团队是认可的，只是没覆盖到「插件 apply() 里注册的定时器」这条路径。

---

建议修复

方案 A（推荐，最小改动）

在进入事务前主动剥掉调用方残留的上下文：

runExclusive(operation) {
  if (this.executing.getStore())
    return Promise.reject(new Error('HMR transactions cannot be nested'))
  const task = this.operations.then(async () => {
    if (this.closing) throw new Error('HMR is disposed')
    return this.executing.run(true, () => this.executing.exit(operation))   // ← 关键改动
  })
  this.operations = task.catch(() => {})
  return task
}

AsyncLocalStorage.exit() 保证 operation 在「无事务标记」的上下文里开始执行。
语义上这正是 runExclusive 的意图——一次独立事务，不该继承调用方残留的上下文。

已实测验证：把该改动施加到上面的最小复现（唯一差别是标 ★ 的那一行），hot 场景失败数从 3/3 降到 0：

function runExclusive(operation) {
  if (als.getStore()) return Promise.reject(new Error('HMR transactions cannot be nested'))
  return new Promise((resolve, reject) => {
    // ★ 方案 A
    als.run(true, () => als.exit(() => Promise.resolve().then(operation)).then(resolve, reject))
  })
}

[fix-A/cold] 心跳次数=3 被拒绝=0
[fix-A/hot]  心跳次数=3 被拒绝=0     ← 修复前是 3/3 失败

方案 B（更彻底，可选叠加）

不要在热重载路径上让插件 fiber 继承事务上下文——在 reload() / fiber.await() 那段用
this.executing.exit(...) 包住，使插件 apply() 从一开始就在干净上下文里执行。
这能同时保护那些「自己注册定时器、但回调里不经过 runExclusive」的插件逻辑
（例如它们若在回调里读 hmr.executing.getStore() 判断状态，也会读到错误的值）。

方案 C（防御性，可选）

把 executing 的标记值从真值 true 改为带身份的对象并校验身份，避免任何「看起来像事务」的残留值命中检查：

const TX = Symbol('hmr-transaction')
// 判定时：this.executing.getStore() === TX

---

影响面

• 纯 CLI / 不热重载插件的用户：不受影响。
• 会在 apply() 里注册周期性任务、且回调中含配置写入的插件：热重载后该能力静默失效，
  每周期一条 HMR transactions cannot be nested，只有重启 DSH 才能恢复。
• 实际案例：一个模型守卫插件在 apply() 里注册了 15 秒心跳，心跳中调
  ctx.agentDefaultModel.saveSelection() 做自动切换模型。热重载后自动切换全线哑火，
  控制台每 15 秒一条该错误，用户看到的是「插件在报错」而不知道切换其实已经失效。
• 由于 hmr.executing 是实例属性、非公开 API，插件侧只能靠 ctx.get('hmr').executing.exit() 临时迂回，
  这属于依赖内部实现，希望官方在内核侧修掉。

---

附：临时规避（供其他插件作者参考）

在插件侧把定时器注册包进「剥掉上下文」的包装里（executing 非公开 API，需做存在性兜底）：

const hmr = ctx.get('hmr')
const runOutsideHmr = (fn) => {
  try {
    const ex = hmr && hmr.executing
    if (ex && typeof ex.getStore === 'function' && typeof ex.exit === 'function' && ex.getStore()) {
      return ex.exit(fn)
    }
  } catch {}
  return fn()
}


runOutsideHmr(() => ctx.interval(tick, 15000))

---

期望行为

runExclusive(operation) 执行 operation 时，其上下文不应继承调用方残留的事务标记；
热重载插件的 apply() 也不应被视为运行在 HMR 事务内。

[Muguett-DBY]

定时器保留 ALS 标记这个判断，与当前 master 的实现是一致的。不过方案 A 不能直接用在现有的队列上：它把 operation 自己的事务标记也清掉了。

这样真正的嵌套调用就不会再被拒绝：

await hmr.runExclusive(async () => {
  await hmr.runExclusive(async () => {})
})

内层任务排在外层后面，外层又在等内层，两个 Promise 都无法结束。另外，现有的 reconcileProfile() 明确要求事务标记为 true；整个 operation 都放进 exit() 后，这个检查也会失败。

可以考虑保留事务上下文，但给每一次事务单独保存一个有生命周期的状态。例如，保留现有队列，只把标记改成：

private readonly executing = new AsyncLocalStorage<{ active: boolean }>()

runExclusive<T>(operation: () => Promise<T>): Promise<T> {
  if (this.executing.getStore()?.active) {
    return Promise.reject(new Error('HMR transactions cannot be nested'))
  }
  const task = this.operations.then(async () => {
    if (this.closing) throw new Error('HMR is disposed')
    const state = { active: true }
    return this.executing.run(state, async () => {
      try {
        return await operation()
      } finally {
        state.active = false
      }
    })
  })
  this.operations = task.catch(() => {})
  return task
}

这样事务结束后，定时器即使还引用着旧对象，读到的也是 active: false；事务尚未结束时，真正的嵌套调用仍然会被拒绝。这里需要 return await operation()，让 finally 在异步操作结束后才清除状态，异常路径也会清除。

这还需要一起调整同文件里另外三处读取：watchConfig() 的回调判断、自身 disposal 时是否等待队列的判断，以及 reconcileProfile() 的检查，都应读取 getStore()?.active。只改 runExclusive() 会留下不一致。方案 C 如果只是换成一个固定的 Symbol，没有增加事务结束时的失效机制，旧定时器仍会保留这个标记。

我用 Codex 辅助核对了源码，并在 Windows / Node 24.22.1 上提取当前 runExclusive()，配合真实 ALS 和定时器做了隔离验证：原实现能复现定时器误报；方案 A 会使上面的嵌套调用悬挂；这个状态对象版本在成功、失败、重复定时器和嵌套调用下符合预期。这里没有启动完整 DSH，也没有跑 Cordis 插件热重载，仍需要在项目内补集成回归。现有的 coordination 测试 已经覆盖真正的嵌套拒绝和事务内自我卸载，修复时这两项也需要保留。

[lingluochengni918]

@Muguett-DBY 谢谢——你的分析和我在你留言后做出来的结果一致，所以我只补数字和细节，不复述论点。

你的两条反驳我这边都复现了，而且方案 A 比「嵌套那一对挂起」更糟。我也跑了一个隔离台（真实 AsyncLocalStorage、真实定时器、队列 + 全部四处读取点；无 DSH 无 Cordis——Node 24.16.0 / dsh-hmr 0.2.1-rc.2），10 场景 × 3 变体：

变体 结果
现行代码 8/10（只有陈旧定时器两条不过）
方案 A（我原提的） 1/10，随后队列卡死，看门狗强制收尾
你的状态对象版 10/10
方案 A 的额外发现：内层任务挂在 this.operations 上永不落定，所以该实例上之后所有 runExclusive 都不再返回——包括完全无关的调用方和自处置路径。现状「一次被拒、其余照常」会退化成「HMR 服务到重启前不可用」。所以我撤回方案 A（包括我给它标的「最小改动」标签）；方案 C 也撤回——你说得对，固定 symbol 没有失效机制，我当时把「身份校验」和「时效校验」混为一谈了。

再给你的版本补一个数据点：长事务进行中触发的定时器仍被正确拒绝，说明修复没有打开「陈旧回调混进活跃事务」的窗口。需要保留的两个行为（真·嵌套仍被拒、事务内自处置）在你的版本下都成立。

你的草案落成 PR 时需要的几个细节（rc.2 与 rc.3 行号一致，我逐字 diff 过；npm next 上的 0.2.1-rc.3 与 rc.2 逐字相同，两个版本都受影响）：

另三处读取要一起改：:772（watchConfig 销毁器：事务内跳过等待队列）、:827（disposal 是否等队列）、:1321（reconcileProfile）；
:1321 有个坑：照搬 getStore() !== true 会永远抛错（对象永远不全等 true），必须写成 getStore()?.active !== true，否则事务内调用过不了它自己的检查。
一个生态提示，值得进 CHANGELOG：executing 虽私有但 JS 可达，绕过这个 bug 的插件在读它（我的就是）。改成对象后真值判断在失效后仍成立，if (getStore()) exit(fn) 会退化成每跳无谓 exit——无害但是永久开销。CHANGELOG 加一行（getStore() 现返回 { active }，请判 ?.active）能让插件作者不必逆向。我已把我这边的守卫改成两种形态都认，并做了变异测试：只把该谓词退回去，陈旧场景就重新走 exit()——说明新分支是承重的，不是摆设。

关于验证：同意——剩下的正是你说的那件事。你的隔离台和我的都没启动真实 DSH、没跑 Cordis 热重载，谁也替代不了仓库内的集成回归。你提到现有 coordination 测试已覆盖真·嵌套拒绝和事务内自我卸载——方便指个文件路径吗？除了那两条，我最想补的一条是：真·嵌套被拒之后，队列仍能继续推进——方案 A 的实测就是「错误修复会把队列永久静默卡死」的直接证据，而我找不到能抓到它的既有断言。如果觉得有用，我可以准备一个只含测试的 PR。

最后帮顶一下求可见性：目前还没有维护者跟进本帖。楼上这段草案 + 这些行号应该够一个 PR 的全部材料，需要保留的两个行为现有 coordination 测试也已覆盖。

[Muguett-DBY]

谢谢你把方案 A 的后果和另外几处读取点都核对了一遍！

测试在 packages/boot/hmr/tests/coordination.spec.ts：

• 第 37–60 行：第一个事务失败后，第二个仍能执行，并在第二个事务里检查真正的嵌套调用会被拒绝。
• 第 103–106 行：事务内自卸载，以及卸载后拒绝新事务。

你说的那条补充确实有价值：现有用例等到了包含嵌套拒绝的第二个事务结束，但没有在那之后再提交第三个事务。可以在 await second 后再跑一次 runExclusive() 并断言它完成，明确覆盖“嵌套被拒后队列仍能前进”。方案 A 会先卡在第二个事务等待嵌套调用的地方；给这类回归设置明确的超时也能避免测试一直挂着。

我这里重新核对了当前 master 的测试源码；这次没有运行完整的 Cordis/HMR 集成测试。

[lingluochengni918]

@Muguett-DBY 行号都核对上了，谢谢。按你的思路写成改动，我这边没跑过仓库环境，请你先过目：

改动 1：第一个用例补第三个事务 + 显式超时

diff

release.resolve(undefined)
await rejection
await second
expect(order).toEqual([1, 2])

• const third = hmr.runExclusive(async () => { order.push(3) })
• await third
• expect(order).toEqual([1, 2, 3])

• })
  +}, 10_000)
  改动 2（可选）：用 it.fails 把 bug 本身钉进测试

ts

it.fails('lets a timer registered inside a transaction start its own transaction afterwards', async () => {
const { ctx, hmr } = await fixture()
const observed = Promise.withResolvers()
await hmr.runExclusive(async () => {
ctx.interval(() => {
hmr.runExclusive(async () => {}).then(
() => observed.resolve(undefined),
() => {}, // 事务内的拒绝是正确行为，忽略；只等事务结束后的那一跳
)
}, 10)
})
await observed.promise
}, 10_000)
两条的意图：改动 1 断言「嵌套被拒后队列仍能前进」，显式超时让队列卡死表现为快速失败；改动 2 复现本帖根因（事务内注册的定时器被 ALS 钉住上下文）——只等「事务结束后」的成功一跳（事务内合法拒绝被忽略，避免误判），现行代码上永不成功→10 秒超时→it.fails 按预期失败；修复合入后成功一跳出现→it.fails 翻转报警，可直接当修复 PR 的验收测试。

两个问题：改动 2 的复现路径（直接在 runExclusive 里调 ctx.interval）和生产事故链路（watcher → apply → interval）形状是否足够一致，你判断；要不要放进同一个 PR，你定。

你跑过没问题我就开 tests-only PR（只改 coordination.spec.ts，描述引用本讨论）。

[Muguett-DBY]

谢谢你把用例写出来！我用 Vitest 4.1.12、真实 AsyncLocalStorage 和定时器做了隔离检查：从当前源码提取的 runExclusive() 在第一条补上第三个事务后能按 [1, 2, 3] 完成。

第二条的思路能复现旧上下文，但现在是吞掉拒绝、等超时；it.fails 也会把无关异常当成预期失败。我试了一个会抛出无关错误的用例，Vitest 同样把它记为 expected fail。可以让定时器在外层结束后，把成功或拒绝都传出来，再明确断言成功：

const observed = Promise.withResolvers<string>()
let outerFinished = false
await hmr.runExclusive(async () => {
  ctx.interval(() => {
    if (!outerFinished) return
    hmr.runExclusive(async () => {}).then(
      () => observed.resolve('ok'),
      error => observed.resolve(error.message),
    )
  }, 10)
})
outerFinished = true
expect(await observed.promise).toBe('ok')

我在隔离队列里看到现有实现返回嵌套错误，状态对象版本返回 ok。这个普通测试适合跟修复一起提交：修复前会失败，修复后应通过，超时只作为兜底。

这里的 ctx.interval 我用原生 setInterval 替代了；没有运行仓库的 Cordis fixture 或真实热重载，所以还不能替代集成验证。另外，项目当前的贡献说明说暂不接受外部 PR，测试草稿先留在讨论里供维护者参考可能更合适。检查时用了 Codex。