src/lib/blog/render.test.ts:164 — "keeps every live TOC anchor resolvable across the authored
corpus" — exceeds the 5000 ms per-test timeout when the full suite runs under coverage
instrumentation, but passes in ~1 s when its file is run alone (9/9 green).
Reproduced on origin/main @ a5df259d with a clean tree, so it is not caused by any current
branch:
Test Files 1 failed | 436 passed (437)
Tests 1 failed | 4610 passed (4611)
It walks the entire authored blog corpus and renders each post, so it is genuinely the heaviest
test in the suite and the first to lose a race for CPU when ~437 files run in parallel with v8
coverage attached.
This matters mostly because a load-sensitive failure that only appears in the full run is
exactly the kind of red that trains people to ignore reds — the pattern #396 and #411 already
cost this repo. Worth either giving it an explicit generous testTimeout, or splitting the
corpus sweep out of the default suite so its cost is visible rather than incidental.
Confirmed local-only. Test (20.x) passed in 8m23s on PR #729 with the same tree that fails
here, so the GitHub runner does not hit it. That makes this a developer-experience problem
rather than a CI one — but it is the worse kind: a red that appears only on the machine where
you are deciding whether your own change broke something.
src/lib/blog/render.test.ts:164— "keeps every live TOC anchor resolvable across the authoredcorpus" — exceeds the 5000 ms per-test timeout when the full suite runs under coverage
instrumentation, but passes in ~1 s when its file is run alone (9/9 green).
Reproduced on
origin/main@a5df259dwith a clean tree, so it is not caused by any currentbranch:
It walks the entire authored blog corpus and renders each post, so it is genuinely the heaviest
test in the suite and the first to lose a race for CPU when ~437 files run in parallel with v8
coverage attached.
This matters mostly because a load-sensitive failure that only appears in the full run is
exactly the kind of red that trains people to ignore reds — the pattern #396 and #411 already
cost this repo. Worth either giving it an explicit generous
testTimeout, or splitting thecorpus sweep out of the default suite so its cost is visible rather than incidental.
Confirmed local-only.
Test (20.x)passed in 8m23s on PR #729 with the same tree that failshere, so the GitHub runner does not hit it. That makes this a developer-experience problem
rather than a CI one — but it is the worse kind: a red that appears only on the machine where
you are deciding whether your own change broke something.