症状
packages/lint/src/lazy-deps.test.ts 的这条用例在整仓 pnpm test 的并发负载下会失败,单独跑 pnpm --filter @objectstack/lint test 必过:
FAIL src/lazy-deps.test.ts > lazy dependency loading (kernel boot-path contract)
> built ESM dist does not load a lazy dep until a react page is validated
❯ src/lazy-deps.test.ts:90:51
失败点是 execFileSync 那一行,实测耗时 5928ms——刚好越过 vitest 默认的 5s 超时。
原因
这条用例 spawn 一个子 node 进程去 import 构建产物,并在子进程里冷加载 sucrase + typescript(各约 1.5MB / 9MB)。在几十个 turbo 任务并行的机器上,这个冷加载本来就会超过 5 秒。
同一文件的兄弟用例已经知道这件事:行 106 的 in-process 版本显式带了 30_000 超时,注释写得很清楚:
Cold-loading sucrase + typescript in-process takes >5s on a loaded CI runner (dozens of parallel turbo tasks) — the default 5s timeout flakes there while the assertion set is pure contract, not latency.
行 81 / 行 90 的两条 dist 探针做同样的冷加载、面临同样的延迟,却沿用默认 5s。这不是契约失败,纯粹是延迟。
建议
给两条 dist 探针用例补上与兄弟用例一致的超时(及同样的说明注释)。断言本身不必动——它们检查的是"哪些依赖被加载了",与耗时无关。
影响
CI 上目前是绿的(Test Core 的负载比本地整仓跑要低),所以这是本地开发者体验问题:任何跑整仓 pnpm test 的人(或 agent)会随机吃到一次红,然后要花时间确认它与自己的改动无关。我在 #3638 期间就撞了三次。
发现于 #3638,与那个 PR 的改动无关,按 AGENTS.md Prime Directive #10 单独立此 issue 而不是就地扩大范围。
症状
packages/lint/src/lazy-deps.test.ts的这条用例在整仓pnpm test的并发负载下会失败,单独跑pnpm --filter @objectstack/lint test必过:失败点是
execFileSync那一行,实测耗时 5928ms——刚好越过 vitest 默认的 5s 超时。原因
这条用例 spawn 一个子
node进程去 import 构建产物,并在子进程里冷加载sucrase+typescript(各约 1.5MB / 9MB)。在几十个 turbo 任务并行的机器上,这个冷加载本来就会超过 5 秒。同一文件的兄弟用例已经知道这件事:行 106 的 in-process 版本显式带了
30_000超时,注释写得很清楚:行 81 / 行 90 的两条 dist 探针做同样的冷加载、面临同样的延迟,却沿用默认 5s。这不是契约失败,纯粹是延迟。
建议
给两条 dist 探针用例补上与兄弟用例一致的超时(及同样的说明注释)。断言本身不必动——它们检查的是"哪些依赖被加载了",与耗时无关。
影响
CI 上目前是绿的(Test Core 的负载比本地整仓跑要低),所以这是本地开发者体验问题:任何跑整仓
pnpm test的人(或 agent)会随机吃到一次红,然后要花时间确认它与自己的改动无关。我在 #3638 期间就撞了三次。发现于 #3638,与那个 PR 的改动无关,按 AGENTS.md Prime Directive #10 单独立此 issue 而不是就地扩大范围。