[0.9.1] `apply()` runs on an inactive fiber — every effect-creating call throws `cannot create effect on inactive context`

[gogoashan-bot]

中文摘要：DSH Desktop 0.9.1（core 0.1.5-rc.2）上，第三方外掛的 apply() 執行時 fiber 已是 inactive 狀態，導致 ctx.on / ctx.inject / ctx.tools.register / ctx.effect 全部被 Fiber.assertActive 拒絕。外掛靜默失效，宿主不中斷。0.6.3 上無此問題。

---

Environment

Item	Value
DSH Desktop	0.9.1 (Windows 10/11 x64)
Harness core (@deepseek-ai/*)	0.1.5-rc.2
@deepseek-ai/cordis	4.0.2
Node	v24.9.0
Previous working version	0.6.3 (core 0.1.1-rc.2)
Profile	web
Onset	Immediately after updating 0.6.3 → 0.9.1

Summary

On every launch of the web profile, several third-party plugins fail their apply() with:

Error: cannot create effect on inactive context

The thrown frames are always inside cordis:

at Fiber.assertActive (…/@deepseek-ai/cordis/lib/index.js:1132:9)
at Proxy.on            (…/@deepseek-ai/cordis/lib/index.js:373:18)   // ctx.on(...)

and the same happens for ctx.inject(...), ctx.tools.register(...), ctx.effect(...).

The plugin's own fiber is already inactive while its apply() is running.

Impact

• Affected plugins load but register nothing — silent, complete loss of function.
• dsh-vision-router (never modified by the reporter) loses all vision routing.
• dsh-context loses tool attribution.
• @liustack/modlens loses its modlens_read_image tool.
• dsh-my-guardian also cannot initialise and says so explicitly.

Each boot emits 12 × cannot create effect on inactive context.

Reproduction

1. Fresh DSH Desktop 0.9.1 on Windows.
2. Launch the web profile containing third-party plugins.
3. Observe %APPDATA%\dsh-desktop\logs\harness.log:

[2026-09-23T05:04:54.482Z] +6125ms [stderr] [modlens] modlens_read_image registration skipped:
                                              Error: cannot create effect on inactive context
[2026-09-23T05:04:54.485Z] +6128ms [stderr] [harness-log] error dsh-context:
                                              Error: cannot create effect on inactive context
[2026-09-23T05:04:54.485Z] +6128ms [stderr] [harness-log]       at Fiber.assertActive
                                              (…/@deepseek-ai/cordis/lib/index.js:1132:9)
[2026-09-23T05:04:54.485Z] +6128ms [stderr] [harness-log]       at Proxy.on
                                              (…/@deepseek-ai/cordis/lib/index.js:373:18)
[2026-09-23T05:04:54.485Z] +6128ms [stderr] [harness-log]       at createToolAttribution
                                              (…/dsh-context/lib/index.js:2045:6)
[2026-09-23T05:04:54.485Z] +6128ms [stderr] [harness-log]       at new apply
                                              (…/dsh-context/lib/index.js:3458:22)
[2026-09-23T05:04:54.485Z] +6128ms [stderr] [harness-log]       at Fiber.execute
                                              (…/@deepseek-ai/cordis/lib/index.js:1067:24)
[2026-09-23T05:04:54.485Z] +6128ms [stderr] [harness-log]       at file:///…/profiles/web/#dsh-context
[2026-09-23T05:04:54.485Z] +6128ms [stderr] [harness-log]       at file:///…/profiles/web/#include

Also emitted on every boot:

warn hmr: Error: failed to apply loader entry dsh-context (dsh-context): cannot create effect on inactive context
warn hmr: Error: failed to apply loader entry vision-router (dsh-vision-router): cannot create effect on inactive context
warn root: [dsh-my-guardian] loader/timer 服务尚未就绪 — guardian 等待局部 inject；本次 apply 暂不初始化（不 fatal）

Expected

A plugin's apply() should run on an active fiber, so that ctx.on / ctx.inject / ctx.tools.register create their effects normally. Registering a service consumer during apply must not be refused.

Hypotheses already tested and falsified (please skip these)

I spent significant effort ruling these out. None of them changed the outcome:

#	Hypothesis	How it was falsified
1	Plugin-specific bug in @liustack/modlens	dsh-vision-router — never modified — fails identically
2	.generations-deferred.json blocking the generation migration	The error first appeared at 02:59:26; the deferred file was first written at 04:45:18 — an hour later
3	The tool-registration call site itself	Wrapping it changed the error's line number but not the outcome — it is a symptom
4	Third-party bundles disabling core rows (id: workspace, `id: ui-sidebar``, …)	Removing the two offending bundles made patch: entry ui-settings-unarchive-sessions not found go to 0, but the inactive-context errors were unchanged
5	plugin node_modules entries being junctions into .generations/live/ vs. real directories	Intervention test: replaced the junctions with real directories (verified byte-for-byte preservation of the generation targets). Result was identical, item for item
6	Duplicate loader entry ids / double mounting	No real duplicates; every plugin appears exactly once in dsh.profile.bundles; no insert: in the profile patch
7	Generation closure bundling a second copy of @deepseek-ai/cordis	The generation's node_modules contains no @deepseek-ai packages at all
8	timer service missing	It is a readiness-timing message, not a missing service; cordis-plugin-timer is present in core

Intervention experiments 4 and 5 are the important ones: changing the hypothesised cause did not change the symptom at all. This strongly suggests the cause is inside cordis's fiber lifecycle during the bundle/plugin tree apply, not in any plugin or profile configuration.

Request

Please confirm whether include / bundle rows on 0.1.5-rc.2 are meant to apply plugins on a fiber that is still active, and whether the loader expects ctx.inject during a bundle apply to be deferred rather than refused.

Happy to provide the full harness.log, the profile's package.json / cordis.patch.yml, or to run any instrumented build you suggest.

[nanami-0713]

把这条的根因往前推了一步：桌面钉住的 0.1.5-rc.2 那套 cordis 系版本里，loader 的重载路径会在 apply 仍在途时整根 dispose 插件 fiber——这正好解释 INACTIVE_EFFECT。证据链如下。

1. 版本对齐表（npm 实测 + 官方仓 tag 核对）

包	本仓（0.9.1）= dsh 0.1.5-rc.2 官方套装	官方 0.1.7-rc.1 套装
@deepseek-ai/cordis	4.0.2	4.0.4
cordis-plugin-loader	1.0.3	1.0.5
cordis-plugin-hmr	1.0.17	1.0.19
cordis-plugin-include	1.0.7	1.0.9
cordis-plugin-group	1.0.2	1.0.4

对照事实：同一批第三方插件（modlens 等）在官方 CLI 0.1.7-rc.1 下正常注册（liustack 在 liustack/modlens#114 里验证过，并把同类报告归到这里）；本仓钉住的正是旧的 0.1.5-rc.2 套装。

2. 机制（cordis 4.0.2 + loader 1.0.3 源码级）

• cordis 4.0.2 的 ctx.plugin() 第一行就是 fiber.assertActive()，而 assertActive() 只在 fiber.uid === null（已被 dispose）时抛——即 cannot create effect on inactive context 的含义是 apply 执行到一半时它的 fiber 已经被拆了，不是"还没启动"。
• loader 1.0.3 的 Entry.update(options, create, force)（lib/index.js）里，只要条目行的 diff 涉及 name / inject / group（或走 force 重载），执行的就是：

await this._dispose(previous);   // 整根拆掉现役 fiber
await this._start(plugin);       // 再重启

而全量 update(config)（patch 层重新 compose 后的整树更新）对每个已存在的行都会走到这条 force 路径；1.0.3 还有一套失败回滚（remove 新建条目 + 重建旧条目），同样在窗口内 dispose fiber。apply 里有 await 的插件（ctx.inject 慢依赖、settings、注册工具前的异步初始化）正好落在窗口里。

• loader 1.0.5 把这块结构性重写了：新增 volatile-config 快路径（config-only 变化直接 fiber._config 热替换，不拆 fiber）、loader/partial-dispose 事件化、整树更新不再对每行 force 重载、失败回滚机械整个移除。这正是"同样插件在 0.1.7-rc.1 下能正常启动"的源码层解释。

3. 触发面（建议在 harness.log 里验证的时间线）

本仓的 dsh-desktop-hmr-fallback 的 registerConfig 会在 cordis.patch.yml 变化时串行触发 patch 层 refresh → loader 整树 update。如果启动期间有任何东西写这个文件（或 profile 的条目行被启动维护 / 市场基线逻辑重写），refresh 就会落在首轮 apply 的窗口内。报告里同 boot 出现的 hmr: failed to apply loader entry … 与这个窗口一致。在 harness.log 里找「INACTIVE_EFFECT 栈之前、首轮 apply 之后」是否有一条 patch-layer/entry 行重写事件，可以把触发者钉死。

4. 建议

把 cordis 家族整套升到 0.1.7-rc.1 对应版本（cordis 4.0.4 / loader 1.0.5 / hmr 1.0.19 / include 1.0.9 / group 1.0.4，注意 1.0.5 的 loader 配 4.0.4 的 cordis 一起动）。modlens 3.26.3 是现成的复现插件（apply 里有多个 await），升级后拿它回归即可。如果需要，我可以提一个只动这五个 pin 的 PR。