pglite-absence's re-import test runs a cold instrumented ORM import on the default 5s timeout

[borisno2]

Surfaced on PR #1281, 2026-09-07. Targets prisma-8, not main.

Symptom

FAIL src/testing/pglite-absence.test.ts > the optional peers are reached only lazily
  > a missing PGlite install is reported by name, with both remedies
Error: Test timed out in 5000ms.

Observed duration: 5132ms against a 5000ms budget — over by 2.6%.

Why this is environmental, not a real regression

• It failed only in test:coverage. The same commit passed the same test in the uninstrumented test run (core: 1603 passed, 0 failed).
• The runner was heavily loaded on the failing attempt: src/db/dev-database.test.ts took 112s and total import time was 91.91s.
• The PR it fired on modified src/testing/context.ts — the module this test dynamically re-imports — but the change is documentation only. The import list is byte-identical before and after, so the module graph did not get heavier.

Why it will keep happening

The test does vi.resetModules() and then a fresh dynamic import('./context.js'), which re-imports a heavy graph including @prisma/orm-postgres/runtime and /control, with coverage instrumentation applied. It runs on the default 5s timeout — packages/core/vitest.config.ts sets no testTimeout.

So the budget for a cold instrumented re-import of the ORM runtime is the same 5 seconds as for a trivial unit test, and it currently lands within ~3% of that ceiling. Any loaded runner tips it over. This will recur on unrelated pull requests and cost a full re-run each time.

Note this is a different mechanism from #1284: that one is an assertion failing on a real invariant, and its fix must not be a timeout bump. This one is a genuine budget mismatch, where the test's subject is an error message rather than latency.

What to build

• The test's timeout reflects what it actually does — a cold, instrumented re-import of the ORM runtime — rather than inheriting the default
• Or the re-import is made cheap enough that the default budget is honest (e.g. narrowing what resetModules forces to reload)
• The assertion itself is unchanged: it must still prove a missing PGlite install is reported by name with both remedies
• Check the sibling tests in the same file for the same latent mismatch

Do not fix this by removing the assertion or by skipping the test.

[borisno2]

A second instance, in a different package — this is a class, not one test. 2026-09-08.

packages/cli/tests/contract-equivalence.test.ts timed out the same way, on PR #1335:

FAIL tests/contract-equivalence.test.ts
  > renderContractModule — the rendered module and the in-process derivation agree
  > blog: identical contract JSON
Error: Test timed out in 5000ms.

Same signature as the original report: a default 5s budget, a test doing genuinely heavy work, failing only in the coverage run, on a loaded runner. The pull request it fired on touches neither packages/cli nor examples/blog.

So the pattern is now:

Test	Package	Work it does on the default 5s budget
src/testing/pglite-absence.test.ts	core	resets the module registry and re-imports the ORM runtime cold
tests/contract-equivalence.test.ts	cli	derives a full contract for an example project and compares it

Neither is a latency test. Both inherit the default timeout that a trivial unit test gets, while doing work measured in seconds, and both are then instrumented by coverage on shared runners.

Widening this issue

The original scope — give one test an honest budget — is too narrow. Suggest instead:

• Audit every test that does heavy work on an inherited default timeout: cold module re-imports, contract derivation, schema application, spawning a real process or server
• Give those an explicit budget reflecting what they actually do, or make the work cheap enough that the default is honest
• Consider whether the coverage run needs a different default from the plain run, since instrumentation is the consistent difference between passing and failing
• Do not fix any of these by removing an assertion or skipping a test

Cost

Each occurrence burns a full re-run on a branch where every delivery wave gates on green. During spec 4 this class has now cost several, and it is currently indistinguishable at a glance from a real regression — which is the more expensive problem, because it trains people to re-run rather than read.

Distinct from #1284, which was an assertion failing on a real invariant and whose fix was explicitly not a timeout change.

[borisno2]

Correcting my previous comment. I wrote that the pull request this fired on "touches neither packages/cli nor examples/blog". That is wrong, and the error matters.

PR #1335 does touch packages/cli, including packages/cli/src/generator/types.ts — the generator whose output contract-equivalence.test.ts renders and compares. It adds a per-list type and a transaction-scoped database interface to the emitted module, which makes that output larger.

So this instance is not cleanly environmental the way the original one was. A plausible mechanism exists: the change enlarges what the generator emits, the test renders and derives that output, and its budget was already marginal. The failure mode is consistent with that — it timed out rather than reporting a mismatch, which is what a slower-but-correct generator would produce.

That does not overturn the broader point. Two tests in two packages doing seconds of real work on an inherited five-second budget, failing only under coverage instrumentation, is still a class worth fixing, and the widening proposed above still stands.

But it does change what should happen to this instance: it may need an explicit budget in the pull request that made the work heavier, rather than being written off as noise. I am treating the re-run as evidence about how marginal it is, not as a verdict that nothing changed.

Apologies for the inaccuracy — I checked the changed-file list only for test files and the example, and missed the generator source.

[borisno2]

Correcting myself again — this time the mechanism, disproved by measurement.

I said PR #1335 plausibly made contract-equivalence.test.ts heavier by enlarging generator output, and that #1329's Tag/PostTag addition to examples/blog would make it heavier still. Both are wrong, established by measuring rather than reasoning:

• That test renders through generator/contract-module.ts, which has no dependency on generator/types.ts — the file The row lock and the advisory lock composed through the raw lane (#1155) #1335 changed. The added per-list type and transaction-scoped interface never reach it.
• Its blog fixture is blogConfig from packages/core/tests/fixtures/contract-configs.ts, a standalone in-repo fixture. It is not derived from examples/blog, so Adding an edge across a junction is a create of the junction row under its own access #1329's new lists do not touch it.

What the numbers actually say

Condition	three runs
The file alone, no coverage	83 / 80 / 78 ms
Full package suite, with coverage	165 / 258 / 209 ms

Against a 5000 ms budget that is a 20–60x margin. A test that fails at 5000 ms while doing 250 ms of work has not run out of time doing work — it never got scheduled. That reframes this whole issue.

The likely mechanism, and it is not "heavy work"

#1335 adds types-row-lock.test.ts: two compile tests that each spawn a TypeScript process with a 300-second budget. Those subprocesses contend for the runner under coverage instrumentation, while this in-process test — first in its file — also pays a cold module-loader start.

So the pattern across all instances is starvation under contention, not a budget honestly exhausted by the test's own work.

What that changes about the fix

The widening I proposed above still holds, but its framing should shift. "Give heavy tests an honest budget" is the wrong lens if the tests are not heavy. Better:

• Identify tests that spawn subprocesses with long budgets, and what they starve when several run under instrumentation
• Decide whether such tests should be isolated from in-process suites rather than every neighbour being given a larger number
• Where a budget is raised, record the measured time it was chosen against, so a future reader can tell a starvation guard from a genuine cost

#1335 sets 30 s on the eight fixtures in that file — about 115x the worst measured coverage run — as a starvation guard, with the measurements above recorded for exactly that reason.