packages/lint/src/runtime-lazy-deps.test.ts has two cases that both pay a
cold module load:
- the subprocess one ends
}, COLD_LOAD_TIMEOUT_MS) (line 121);
it('gating a flow in-process loads neither dep, and still finds the defect', …)
(line 124) ends }) — vitest's default 5000 ms — even though its first act is
await import('./runtime.js'), i.e. the same cold graph load, in-process.
Under a loaded machine (several agents' suites sharing one container) the
in-process one intermittently exceeds 5 s:
× gating a flow in-process loads neither dep, and still finds the defect 5004ms
FAIL src/runtime-lazy-deps.test.ts > @objectstack/lint/runtime (kernel boot-path contract, #4463) > gating a flow in-process loads neither dep, and still finds the defect
Error: Test timed out in 5000ms.
Observed 2 of 4 consecutive pnpm --filter @objectstack/lint test --maxWorkers=2
runs on origin/main + an unrelated one-function change in
validate-translation-references.ts; the other 2 runs were fully green
(1202 passed). Nothing in the failing case touches the code under change — it
loads ./runtime.js and inspects require.cache.
Why it matters
It is a false red on whatever PR happens to run while the box is busy, on a test
whose actual claim (the boot path loads no source parser) is unaffected by wall
clock. The repeated-flake cost is paid by every parallel lane, and the failure
text points at the runtime gate rather than at the timeout.
Suggested fix
Give the in-process case the same explicit timeout its sibling already uses —
}, COLD_LOAD_TIMEOUT_MS) — so both cold-load cases state the same budget. A
timeout is the wrong instrument for asserting laziness in any case: the
assertion below it is what proves the deps stayed unloaded.
Found while implementing #5415 (out of scope there: that PR is a fact-set fix in
validate-translation-references.ts and does not touch the runtime entry).
Verified against origin/main d0856707f.
packages/lint/src/runtime-lazy-deps.test.tshas two cases that both pay acold module load:
}, COLD_LOAD_TIMEOUT_MS)(line 121);it('gating a flow in-process loads neither dep, and still finds the defect', …)(line 124) ends
})— vitest's default 5000 ms — even though its first act isawait import('./runtime.js'), i.e. the same cold graph load, in-process.Under a loaded machine (several agents' suites sharing one container) the
in-process one intermittently exceeds 5 s:
Observed 2 of 4 consecutive
pnpm --filter @objectstack/lint test --maxWorkers=2runs on
origin/main+ an unrelated one-function change invalidate-translation-references.ts; the other 2 runs were fully green(1202 passed). Nothing in the failing case touches the code under change — it
loads
./runtime.jsand inspectsrequire.cache.Why it matters
It is a false red on whatever PR happens to run while the box is busy, on a test
whose actual claim (the boot path loads no source parser) is unaffected by wall
clock. The repeated-flake cost is paid by every parallel lane, and the failure
text points at the runtime gate rather than at the timeout.
Suggested fix
Give the in-process case the same explicit timeout its sibling already uses —
}, COLD_LOAD_TIMEOUT_MS)— so both cold-load cases state the same budget. Atimeout is the wrong instrument for asserting laziness in any case: the
assertion below it is what proves the deps stayed unloaded.
Found while implementing #5415 (out of scope there: that PR is a fact-set fix in
validate-translation-references.tsand does not touch the runtime entry).Verified against
origin/maind0856707f.