RunProcess polled the child with an exponential backoff that capped at
100 ms, so every test longer than roughly 300 ms paid 30-75 ms of
latency after it had already exited. Across the parallel suite that
adds up to about 160 thread-seconds.
Block in wait() instead and let a timer thread deliver the kill when
the timeout is crossed. Set the shutdown flag from the SIGINT handler
so a worker whose child died from the same ctrl-c does not report it
as a failure before the main thread aborts the run.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UH48w8TCtYmHd4P2UE6HEY
Signed-off-by: Matteo Collina <hello@matteocollina.com>
PR-URL: https://github.com/nodejs/node/pull/66432
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Filip Skokan <panva.ip@gmail.com>
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
Reviewed-By: Moshe Atlow <moshe@atlow.co.il>
RunProcess sleeps after polling even when the child has already exited.
Skip that sleep, saving up to 100 ms per test.
Sort --time results in descending order to display the 20 slowest tests.
Signed-off-by: Filip Skokan <panva.ip@gmail.com>
Assisted-by: Codex
PR-URL: https://github.com/nodejs/node/pull/65980
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: LiviaMedeiros <livia@cirno.name>
Previously for each matching test, it would execute multiple
`node -p` commands to decide the configurations of the executable.
That means if there are 100 tests matched, it will run the Node.js
executable 4*100 times to retrieve the same configurations repeatedly.
This changes the loop order so that it only execute these commands
once and reuse the results for all matching tests.
PR-URL: https://github.com/nodejs/node/pull/60266
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: Chengzhong Wu <legendecas@gmail.com>
Previously, selecting subsystems with numbers in their names, like
http2, weren't matched due to a restrictive regex:
```
$ tools/test.py http2
No tests to run.
```
The regex now allows digits, so these tests run as expected:
```
$ tools/test.py http2
[00:17|% 100|+ 286|- 0]: Done
All tests passed.
```
Signed-off-by: Darshan Sen <raisinten@gmail.com>
PR-URL: https://github.com/nodejs/node/pull/59242
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Marco Ippolito <marcoippolito54@gmail.com>
The output of `node -p process.config.variables.asan` includes
a newline character so it's never exactly "1", which means
asan is always "off" for the status files. This fixes the
detection by stripping whitespaces from the output.
PR-URL: https://github.com/nodejs/node/pull/52766
Reviewed-By: Rafael Gonzaga <rafael.nunu@hotmail.com>
We run all WPT from one subset in the same process using workers.
As the number of the tests grow, it can take longer to run some of the
subsets, but it's still overall faster than running them in different
processes. This patch increases the timeout
for WPT to prevent the test from failing because it takes longer
to run (even though it would still complete at some point).
PR-URL: https://github.com/nodejs/node/pull/44574
Refs: https://github.com/nodejs/reliability/issues/371
Reviewed-By: Tobias Nießen <tniessen@tnie.de>
Reviewed-By: Filip Skokan <panva.ip@gmail.com>
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
test-benchmark-buffer is consistently timing out on a single Windows
host in CI. Rather than try to figure out if we need to scale the
timeout up for a certain memory limit or chip speed or something else,
let's increase the timeout for benchmark tests in general.
PR-URL: https://github.com/nodejs/node/pull/40684
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: Tobias Nießen <tniessen@tnie.de>
Reviewed-By: Voltrex <mohammadkeyvanzade94@gmail.com>
`output.diagnostic` is a list that is appended to on SmartOS when
retrying a test due to `ECONNREFUSED`. The test runner checks if
`output.diagnostic` is truthy and, if so, assigns its value to
`self.traceback`. However `self.traceback` is supposed to be a string,
and `_printDiagnostic()` in the `TapProgressIndicator` attempts to call
`splitlines()` on it, which fails if it is a list with:
AttributeError: 'list' object has no attribute 'splitlines'
PR-URL: https://github.com/nodejs/node/pull/38289
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Christian Clauss <cclauss@me.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
It's possible to annotate failures in Actions by printing
"::error file={},line={},col={}::{message}". This methos is preferrable
over using a problem matcher because problem matchers only allow
single-line messages, whereas ::error allows multi-line messages.
PR-URL: https://github.com/nodejs/node/pull/34590
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
This fixes the following crash on Windows for me. I don't know
why this I only started to see this now, but anyway, the new timeout
value is still longer than a week and a half.
File "tools/test.py", line 1725, in <module>
sys.exit(Main())
File "tools/test.py", line 1701, in Main
if RunTestCases(cases_to_run, options.progress, \
options.j, options.flaky_tests):
File "tools/test.py", line 923, in RunTestCases
return progress.Run(tasks)
File "tools/test.py", line 145, in Run
thread.join(timeout=10000000)
File "C:\Users\anna\AppData\Local\Programs\Python\Python38-32\ \
lib\threading.py", line 1015, in join
self._wait_for_tstate_lock(timeout=max(timeout, 0))
File "C:\Users\anna\AppData\Local\Programs\Python\Python38-32\ \
lib\threading.py", line 1027, in _wait_for_tstate_lock
elif lock.acquire(block, timeout):
OverflowError: timeout value is too large
PR-URL: https://github.com/nodejs/node/pull/32868
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Jeremiah Senkpiel <fishrock123@rocketmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: Zeyu Yang <himself65@outlook.com>
Reviewed-By: Bartosz Sosnowski <bartosz@janeasystems.com>
Filip Skokan