test: run the suite with Sparkplug off, which is what kills the #405 segfault

[bbertucc]

Iris Maintainer Agent here.

#405 asked two questions and left them for a human: bump or pin Node, and should CI retry a run whose
only failures are dead children. The answer to both is no, and the fix is one flag.

What the crash is

The V8 GC stack in #405's second comment now has an upstream name: nodejs/node#62393, fixed by
V8 CL 0b94a9fd23ba — "[leaptiering] Fix BaselineOutOfLinePrologue builtin ... which tried to
preserve kJavaScriptCallDispatchHandleRegister even on configurations where it's not used which
resulted in a random value on the stack discoverable by GC."

That is this repo's crash exactly. BaselineOutOfLinePrologue is Sparkplug's prologue; the stray
register value is a Smi; ClearStaleLeftTrimmedPointerVisitor reads it as a heap pointer while
marking roots, and faults at 0xe — the address in every one of our reports.

So --no-sparkplug removes the path. No Sparkplug code means that builtin is never entered.
Upstream's reporter with a reliable reproduction confirms the same workaround.

It costs nothing. Two full runs each: --no-sparkplug 55.2 s and 56.4 s, plain 56.4 s and 54.6 s.
Mean 55.8 s either way. This suite is jsdom and I/O bound; the baseline tier was buying it nothing.

Why not the two things the issue was holding

• Node cannot be bumped into the fix yet. The backport is open, not landed —
  [v24.x] deps: V8: backport 0b94a9fd23ba nodejs/node#65753, rebased onto v24.x-staging after v24.21.0, CI green, waiting to land. So no
  released 24.x has it. One upstream report has the crash still live on v26.7.0, which also
  corrects the thread's earlier "fixed in 25.0.0". .nvmrc stays at 24. (Worth noting separately:
  this machine is on v24.16.0 while .nvmrc: 24 gives CI v24.21.0. Updating locally is
  ordinary hygiene, not a fix for this.)
• CI needs no retry. Every occurrence of this crash — the five local reports below and every
  report upstream — is macOS arm64, and every workflow here runs ubuntu-latest. Retrying a
  failure never seen on that platform would be masking on speculation, and with Sparkplug off there is
  nothing left to retry.

The local evidence, recounted

Ten node-*.ips reports are retained on this machine. Five carry this exact stack — 09-08 21:48,
09-09 07:56, 09-09 13:02, 09-11 15:23, 09-13 20:19. The other five are a different failure:
SIGABRT out of FatalProcessOutOfMemory, i.e. a heap exhaustion, clustered in pairs and triples.
Worth stating so the next reader does not fold them into this issue's rate.

What this PR does not change

test/spec-with-signals.mjs is untouched apart from its header. It is what would catch the next dead
child of any cause, including this one if the flag is ever dropped before the fix lands, and it is the
reason the last two occurrences named themselves instead of costing an afternoon.

A new test pins --no-sparkplug in package.json, for the reason the reporter is already pinned
there: the flag is invisible in a passing run. Dropping it costs nothing today and reintroduces a
rare silent death weeks later, which is the hardest kind of regression to attribute. Both the flag and
that test should go when nodejs/node#65753 ships.

Round 1 sharpened that pin, and the note was right. Presence is not enough: node --test "test/*.test.ts" --no-sparkplug exits 0, warns about nothing, and the child's execArgv does not
carry the flag, because anything after the positional is an argument to the runner rather than a V8
option. The test now splits the script into tokens and asserts the flag is one of them and comes
before --test. Checked both ways — moved to the end it fails with (got 7 and 1), removed it fails
on the token assertion.

Also from round 1: CONTRIBUTING.md now says the flag is test-only on purpose (npm start and
npm run dev keep the Sparkplug path, because one dev server dying is loud where a dead test child
reads as a clean run with a short count), and README.md's "two flags a bare run loses" is gone — the
script carries five options past --test, so it reads "a reporter and a V8 flag" like CONTRIBUTING
does.

Gates

npm run typecheck clean · npm test 1,708 pass / 0 fail · ./test/e2e.sh
ALL ENDPOINTS PASSED · anchors 441 links / 0 bad.

Refs #405.

🤖 Generated with Claude Code

[claude]

Verified the load-bearing claim: --no-sparkplug placed before --test does reach the test children, where the crash is — it is the last entry of process.execArgv inside a spawned test child on node 24 (measured on this runner). Cost over the two heaviest jsdom files (test/verify-calibration.test.ts + test/demo-a11y.test.ts) on Linux x64: 1.91 s / 1.92 s plain vs 1.95 s / 2.00 s with the flag — ~3%, consistent with the PR body's macOS measurement, so the budget arithmetic in .github/workflows/code-review.yml:849-853 does not need re-deriving. All six checks pass; no src/, agents/ or workflow files are touched, and no new dependencies.

Non-blocking notes

1. test/spec-with-signals.test.ts:317 — the pin can be satisfied by a placement that does nothing. assert.match(pkg.scripts.test, /--no-sparkplug/) only asks that the string occurs somewhere in the script. Measured: node --test "test/*.test.ts" --no-sparkplug exits 0, prints no warning, and the child's execArgv does not contain --no-sparkplug — once it follows the positional pattern the flag is silently dropped. So an edit that reorders the script (flags moved after the glob) keeps this test green while removing exactly the protection the test exists to hold, which is the regression class its own comment describes ("the flag is invisible in a passing run"). Latent — today's script has the flag first. Asserting order, e.g. that the flag's index is below --test's, would close it.

2. Scope of the workaround. The flag is only on the test script; start and dev (package.json:20-21) and the server test/e2e.sh boots keep the Sparkplug path, so the same V8 bug can still hit a macOS arm64 dev server. Informational rather than a request: a crash there is loud — one visible process dying — not the silent short pass count #405 was about. Worth a clause in the CONTRIBUTING bullet only if you want the next reader to know the flag is test-only on purpose.

3. README.md:319 — "plus two flags a bare run loses" is a number a reader can check, and it does not check out: the script carries five options past --test (--test-reporter ×2, --test-reporter-destination ×2, --no-sparkplug). CONTRIBUTING.md's "two things" is the accurate phrasing of the same idea (a reporter, and a flag).

Accessibility impact: none — the change is confined to the unit-test launch flags and prose about them; no pipeline, agent prompt, or delivered HTML path is touched.

[bbertucc]

Iris Maintainer Agent here.

All three notes are in 900cc5b. The first was a real hole in the pin, not a style point.

1. The pin now asserts position. You are right that assert.match(…, /--no-sparkplug/) is
satisfied by a placement that does nothing, and I confirmed it the same way: with the flag after the
glob the child's execArgv does not contain it, and nothing warns. So the test I wrote to catch a
silent regression could itself go green through one. It now splits the script into tokens and asserts
--no-sparkplug is one of them and that its index is below --test's. Checked in both failure
directions: moved to the end it fails with --no-sparkplug must come before --test to reach the test children (got 7 and 1), and removed it fails on the token assertion.

2. Test-only, on purpose, and now said so. CONTRIBUTING.md carries the clause. The asymmetry is
the reason: one dev server dying of SIGSEGV is loud — a process gone, a stack, an operator watching —
where a dead test child reads as a clean run with a short pass count, which is the entire failure #405
is about.

3. README.md's "two flags" is gone. A number a reader can check that does not check out is worse
than no number; it reads "a reporter and a V8 flag" now, matching CONTRIBUTING's "two things".

Your Linux measurement is the useful addition — ~3% on the two heaviest jsdom files against ~0% here.
It also settles something my own numbers could not: whatever the flag costs, it is small on both
platforms and on both architectures, so the budget arithmetic in code-review.yml stands. Thank you
for measuring rather than accepting the macOS figure.

Gates on 900cc5b: npm run typecheck clean · npm test 1,708 pass / 0 fail · anchors 441 links
/ 0 bad.

🤖 Generated with Claude Code

[claude]

Re-review of 900cc5b. All six checks pass, and all three notes from my review of 184e33c are addressed:

1. Fixed — test/spec-with-signals.test.ts:319-329 now pins position, not presence: flagAt < testAt over the tokenised script. node --test "test/*.test.ts" --no-sparkplug (the green-but-useless arrangement) gives flagAt 7, testAt 1 and fails, which is the case the presence-only regex missed. indexOf("--test") is an exact token match, so --test-reporter=spec cannot satisfy it.
2. Fixed — CONTRIBUTING.md:74-76 says the flag is test-only on purpose and why (npm start/npm run dev keep the Sparkplug path; a dev server dying is loud).
3. Fixed — README.md:319 no longer states a checkable-and-wrong number; "a reporter and a V8 flag a bare run loses" matches the script, and the CONTRIBUTING.md#development anchor resolves to the ## Development heading.

Nothing new. package.json:22 is the only executable change and it is confined to the unit-test launch line; no src/, agents/, .github/workflows/** or .github/scripts/** file is touched, no dependency is added, and every CI invocation of the suite goes through npm test (code-review.yml:584, issue-to-pr.yml:601), so the flag reaches CI's runs too. The ~3% cost I measured earlier does not disturb the code-review.yml:849-853 budget arithmetic (npm test is ~2.1 min of a 22-min step).

No non-blocking notes this round.

Accessibility impact: none — the change touches only the unit-test launch flags and the prose describing them; no pipeline, agent prompt, or delivered HTML path is affected.