Error: cannot get required service "sessionProjections" in inactive context after running several tasks

[liren2272-hue]

Here comes a fatal problem to me. Have other users found similiar problems? The issue is summarized by DSH.

Bug: Error: cannot get required service "sessionProjections" in inactive context after running several tasks

环境 / Environment

• DSH 版本: 0.2.1-rc.2（@deepseek-ai/dsh-desktop-runtime，见 package.json 的 version 字段，所有 @deepseek-ai/dsh-* / @deepseek-ai/cordis 依赖均为该 RC 版本）
• 受影响包:
  • @deepseek-ai/dsh-agent-loop 0.2.1-rc.2
  • @deepseek-ai/dsh-session-projection 0.2.1-rc.2
  • @deepseek-ai/cordis 4.0.5（vendor，反射/注入层）
• 平台: Windows 11 / Electron（resources/app.asar 打包）
• 复现概率: 跑多个任务（多个 subagent / background job / 长时 agent 运行）后，短时间（"不久"）内必然出现，且会蔓延到该会话的所有工具调用（包括 read/bash/glob/working_directory），导致整个会话瘫痪，只能靠新建会话恢复 active context。

复现步骤 / Reproduction

1. 在 DSH 中连续发起多个并行/串行任务（subagent、background job、workflow 等）。

2. 让部分任务（子 agent / scope）完成并进入 teardown，同时其他任务继续运行，制造频繁的 scope 创建 / 销毁。

3. 观察数分钟到数十分钟后，随机一次工具调用或 loop 内部访问抛：

   Error: cannot get required service "sessionProjections" in inactive context
   

4. 此后该会话的所有工具调用持续返回同一错误，直到新建会话。

实测佐证：报告撰写者的 agent 会话本身就现场复现过——上一轮会话所有工具（含 working_directory）均返回同一条错误，新建 active 会话后立即恢复正常，可直接读取源码，证明这是"失效 context"问题而非用户任务逻辑。

错误源码定位 / Root-cause source trace

1. 错误抛出点（Cordis 反射/注入层）

jsonl/lib/worker.cjs（即 vendor/cordis/src/reflect.ts 的编译产物）：

// worker.cjs:2442-2444  ReflectService.handler.get
if (prop in fiber.inject) {
  error.message = `cannot get required service "${prop}" in inactive context`;
  throw error;
}

含义：组件在 inject 中声明了 sessionProjections，但读取时所在的 fiber / context 已被 dispose（状态 INACTIVE/__INACTIVE__，见 worker.cjs:1963、_setEpoch(INACTIVE)）。 Cordis 会沿父级 fiber 向上查找，但路径上第一个命中 inject 且已 inactive 的就直接抛错，不会回落到仍存活的父级运行时。相关常量：INACTIVE_EFFECT（worker.cjs:1961）、INACTIVE = "__INACTIVE__"（worker.cjs:1963）。

2. 服务定义

@deepseek-ai/dsh-session-projection/lib/index.js：SessionProjectionRegistry extends Service，以 super(ctx, "sessionProjections") 注册在根 app 上下文，承载每会话的投影状态（inbox、turnBoundary、runtimeContext 等），通过 session/event 订阅做 eager drive。

3. 触发点（消费方）

@deepseek-ai/dsh-agent-loop/lib/index.js：

• 每个 agent / 子任务 createScope(loopCtx, this) 建子 scope 上下文，this.ctx = this.scope.ctx（:778-779）。
• 大量通过 this.ctx.sessionProjections 访问投影服务（绑定在子 scope 上）：
  • new ReactLoopInbox(this.ctx.sessionProjections, session, this.dispatch)（:780）
  • this.loopCtx.sessionProjections.stateOf(session, "turnBoundary")（:782）
  • 注册投影：ctx.effect(function*(){ const unregisterTurnBoundary = ctx.sessionProjections.register(...); ... })（:1580-1589），disposer 绑在 fiber 上。
• 当任务完成 / 子 agent 结束 / scope 回收时，该 scope 的 fiber runtime 进入 inactive。

根因：scope 被 dispose 之后，仍有延迟执行逻辑（inbox 变更、turnBoundary 更新、change-feed 监听回调、ownership teardown 回调等）继续用 this.ctx.sessionProjections（已死 scope）去读投影服务。第一次在 dispose 后触发的访问即抛 "in inactive context"。任务越多、scope 生灭越频繁，撞上失效访问的概率越高 → "跑一阵就全挂"。

佐证：同文件 ReactLoopInbox.current() 已写过正确的同类守卫

if (state === void 0) throw new Error(`agent "${this.session.id}" cannot read inbox state: its projection registration is not active`);

且多处已有 if (!this.ownership.isActive()) return;（:1625/:1643/:1651/:2009）的 active 守卫惯例——但投影访问路径未全覆盖。

建议修复 / Suggested fixes

临时规避（用户侧）

• 会话卡死时新建会话恢复 active context（最有效）。
• 降低并发：maxParallelToolCalls 默认 10（:1554），压低并行 subagent / background job 数量。
• 任务结束前 job_kill 或等子任务回写完成，避免它们在会话失活后回碰会话级服务。
• 关注是否有更新的 build（当前为 RC）。

代码层根治（维护者侧，按优先级）

1. 投影访问绑定活根上下文：延迟回调 / teardown / ReactLoopInbox 调用时不要持有 this.ctx.sessionProjections（子 scope，随 dispose 失效），改为捕获并保持 this.loopCtx.sessionProjections（根/loop 上下文，不受子 scope dispose 影响）。
2. 所有延迟 / teardown 访问前加 active 守卫：对齐既有 if (!this.ownership.isActive()) return; / 检查 fiber.runtime，把失效访问在用户态短路，而非交给 Cordis 抛底层错。
3. 监听器随 scope 注销：SessionProjectionRegistry.listeners（全局 Set）注册了 change-feed 监听的 scope 一旦 dispose，其回调若仍引用失效 session/scope 会回调进死 ctx；确保 scope 卸载时从 listeners 移除回调。
4. 注册 disposer 收尾幂等 + 读取侧安全降级：ctx.effect 中 unregisterInbox/TurnBoundary（:1585-1588）在 scope dispose 后才执行，期间其他组件读该 key 会命中 "registration not active"；让 stateOf / 读取侧在注册已卸时安全降级（参考既有 state === void 0 守卫），而非抛错中断整个 loop。
5. （框架层，谨慎） 可在 ReflectService.handler.get 中，当本 fiber inactive 但父级仍有 live 运行时提供该服务时回落到父级——会改变注入语义，风险高，优先在用法侧（1–4）修。

补充 / Notes

• 源码取自本地 unpacked 副本：C:/Users/15940/Documents/deepseek-harness/default-workspace/_work/pkg/（dsh-agent-loop、dsh-session-projection、jsonl 等），与 resources/app.asar 内 0.2.1-rc.2 一致。
• 该错误类（inactive context）一旦发生会阻塞整个会话的全部工具调用，建议作为**阻断级（blocker）**问题处理，而非普通 bug。

[PerryLink]

The line you found is the right one, and the mechanics around it explain the part of the symptom that looks like a bug in the service.

vendor/cordis/src/reflect.ts:136-171 is the context proxy's get trap. For a name that is not a plain property, it walks the fiber chain at :155-166:

let fiber = (ctx[symbols.shadow] as Context ?? ctx).fiber
while (true) {
  const impl = fiber.store?.[prop]
  if (impl) return getTraceable(ctx, impl.value)
  if (prop in fiber.inject) {
    error.message = `cannot get required service "${prop}" in inactive context`
    throw error
  }
  if (!fiber.runtime) throw error
  if (fiber.parent[symbols.isolate][prop] !== key) throw error
  fiber = fiber.parent.fiber
}

The important detail is the ordering. The service store is only populated while a fiber is loaded, so for an inactive fiber fiber.store?.[prop] is undefined and the prop in fiber.inject test — checked before the walk continues at :163-165 — fires immediately. The error therefore means "the context you read through belongs to a fiber that declared this dependency and is not loaded", not "this process has no sessionProjections". That matches your diagnosis, and it is worth stating that way because the message invites the opposite reading.

It also explains the spread you describe. One retained context from a torn-down scope is enough: every later read through it throws, and tool calls all go through that scope, so one stale reference looks like a whole-session failure while a fresh session works.

Two cautions for the write-up. INACTIVE_EFFECT (fiber.ts:172, "cannot create effect on inactive context") is a different error from this one — adjacent condition, different consequence — so don't merge the two codes in the report. And the message carries no identity of the offending fiber, which is why the report cannot name an entry: whoever reads it needs the stack. If you can reproduce again, capture the stack of the first throw and, if possible, the options.id of the loader entry whose fiber it is; that turns "some stale context" into a named row.