Previously `--test-timeout` is set on per test execution, this is
obviously a bug as per test execution is hard to be expected, this patch
addresses the issue by setting `timeout` from per execution to per test.

This patch also fixes a minor issue that `--test-timeout` is not being
respected when running without `--test`.

PR-URL: #57672
Fixes: #57656
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Pietro Marchini <pietro.marchini94@gmail.com>
Reviewed-By: Moshe Atlow <moshe@atlow.co.il>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>

Previously `--test-timeout` is set on per test execution, this is
obviously a bug as per test execution is hard to be expected, this patch
addresses the issue by setting `timeout` from per execution to per test.

This patch also fixes a minor issue that `--test-timeout` is not being
respected when running without `--test`.

PR-URL: #57672
Fixes: #57656
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Pietro Marchini <pietro.marchini94@gmail.com>
Reviewed-By: Moshe Atlow <moshe@atlow.co.il>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>

…child

Two fixes for the same failure mode -- an unbounded wait turning a failure
into a hang. `npm test` runs unattended inside release.sh, so a hang wedges
the release rather than aborting it.

1. The concrete defect. The credential-race test forks children and waits on
   `child.once("message")` for a "ready" signal, with nothing on the failure
   path. A child that dies BEFORE signalling -- an import throw, a stale
   build -- never sends it, so the promise stays pending forever and the whole
   suite hangs. It now also settles on `exit`, reporting the child's own exit
   code. A late exit after res() is a no-op on an already-settled promise,
   which is the normal path here: these children are expected to exit once
   the race has been signalled.

2. The backstop. node:test has no default per-test timeout, so any future
   unbounded wait has the same effect. --test-timeout=300000 is deliberately
   generous -- measured files run ~7.5s worst case, so 5 minutes is ~40x
   headroom and cannot false-fail, while still converting a hang into a
   reported failure.

Note the semantics: until Node 24 the flag is per-FILE, not per-test
(nodejs/node#57672), so the value must clear the slowest FILE. Requires
Node >= 20.11.0 (nodejs/node#50443); dev-side script only, so engines is
left alone.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

… a release

node:test has NO default per-test timeout, so a test awaiting an event that
never arrives runs forever. `npm test` runs unattended inside release.sh, so
that turns a wedged release rather than a failed one -- the release just never
returns.

--test-timeout=300000 is a backstop, deliberately generous: measured test files
run ~7.5s worst case here, so 5 minutes is roughly 40x headroom and cannot
false-fail, while still converting an infinite hang into a reported failure.

Note the semantics: until Node 24 the flag is per-FILE, not per-test
(nodejs/node#57672), so the value has to clear the slowest FILE. Verified
empirically rather than assumed -- and note that Node already catches the
easy case (a pending promise with a drained event loop) on its own; the case
this flag actually covers is a hang holding a live handle, e.g. a child
process that never messages back.

Requires Node >= 20.11.0 (nodejs/node#50443). This affects the dev-side test
script only, not package consumers, so engines is left alone.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

… a release

node:test has NO default per-test timeout, so a test awaiting an event that
never arrives runs forever. `npm test` runs unattended inside release.sh, so
that turns a wedged release rather than a failed one -- the release just never
returns.

--test-timeout=300000 is a backstop, deliberately generous: measured test files
run ~7.5s worst case here, so 5 minutes is roughly 40x headroom and cannot
false-fail, while still converting an infinite hang into a reported failure.

Note the semantics: until Node 24 the flag is per-FILE, not per-test
(nodejs/node#57672), so the value has to clear the slowest FILE. Verified
empirically rather than assumed -- and note that Node already catches the
easy case (a pending promise with a drained event loop) on its own; the case
this flag actually covers is a hang holding a live handle, e.g. a child
process that never messages back.

Requires Node >= 20.11.0 (nodejs/node#50443). This affects the dev-side test
script only, not package consumers, so engines is left alone.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

… a release

node:test has NO default per-test timeout, so a test awaiting an event that
never arrives runs forever. `npm test` runs unattended inside release.sh, so
that turns a wedged release rather than a failed one -- the release just never
returns.

--test-timeout=300000 is a backstop, deliberately generous: measured test files
run ~7.5s worst case here, so 5 minutes is roughly 40x headroom and cannot
false-fail, while still converting an infinite hang into a reported failure.

Note the semantics: until Node 24 the flag is per-FILE, not per-test
(nodejs/node#57672), so the value has to clear the slowest FILE. Verified
empirically rather than assumed -- and note that Node already catches the
easy case (a pending promise with a drained event loop) on its own; the case
this flag actually covers is a hang holding a live handle, e.g. a child
process that never messages back.

Requires Node >= 20.11.0 (nodejs/node#50443). This affects the dev-side test
script only, not package consumers, so engines is left alone.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

… a release

node:test has NO default per-test timeout, so a test awaiting an event that
never arrives runs forever. `npm test` runs unattended inside release.sh, so
that turns a wedged release rather than a failed one -- the release just never
returns.

--test-timeout=300000 is a backstop, deliberately generous: measured test files
run ~7.5s worst case here, so 5 minutes is roughly 40x headroom and cannot
false-fail, while still converting an infinite hang into a reported failure.

Note the semantics: until Node 24 the flag is per-FILE, not per-test
(nodejs/node#57672), so the value has to clear the slowest FILE. Verified
empirically rather than assumed -- and note that Node already catches the
easy case (a pending promise with a drained event loop) on its own; the case
this flag actually covers is a hang holding a live handle, e.g. a child
process that never messages back.

Requires Node >= 20.11.0 (nodejs/node#50443). This affects the dev-side test
script only, not package consumers, so engines is left alone.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

… a release

node:test has NO default per-test timeout, so a test awaiting an event that
never arrives runs forever. `npm test` runs unattended inside release.sh, so
that turns a wedged release rather than a failed one -- the release just never
returns.

--test-timeout=300000 is a backstop, deliberately generous: measured test files
run ~7.5s worst case here, so 5 minutes is roughly 40x headroom and cannot
false-fail, while still converting an infinite hang into a reported failure.

Note the semantics: until Node 24 the flag is per-FILE, not per-test
(nodejs/node#57672), so the value has to clear the slowest FILE. Verified
empirically rather than assumed -- and note that Node already catches the
easy case (a pending promise with a drained event loop) on its own; the case
this flag actually covers is a hang holding a live handle, e.g. a child
process that never messages back.

Requires Node >= 20.11.0 (nodejs/node#50443). This affects the dev-side test
script only, not package consumers, so engines is left alone.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>