I missed marking a couple of test cases flaky in my previous PR:
https://github.com/nodejs/node/pull/58583
tests missed were:
- parallel.test-inspector-network-content-type
- benchmark.test-benchmark-websocket
After marking the above flaky I re-ran a test build and noticed
the build still failed.
Unfortuantely the build still fails because the build detects that
node process are left behind after the tests, presumably because tests
that spawn child processes are being timed out and only the parent
process is killed off, leaving the child processes behind.
see: https://github.com/nodejs/node/pull/59014#issuecomment-3057162303
We've decided to skip these tests until the underlying issue is
resolved.
The tests being skipped are:
- parallel.test-http-proxy-fetch
- parallel.test-https-proxy-fetch
- benchmark.test-benchmark-websocket
- parallel.test-inspector-network-fetch
- parallel.test-inspector-network-content-type
- es-module.test-wasm-web-api
- parallel.test-fetch
- parallel.test-without-async-context-frame
- report.test-report-exclude-network
PR-URL: https://github.com/nodejs/node/pull/59014
Reviewed-By: Richard Lau <richard.lau@ibm.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Michael Dawson <midawson@redhat.com>
There are several cleanups here that are not just style nits...
1. The `common.isMainThread` was just a passthrough to the
`isMainThread` export on the worker_thread module. It's
use was inconsistent and just obfuscated the fact that
the test file depend on the `worker_threads` built-in.
By eliminating it we simplify the test harness a bit and
make it clearer which tests depend on the worker_threads
check.
2. The `common.isDumbTerminal` is fairly unnecesary since
that just wraps a public API check.
3. Several of the `common.skipIf....` checks were inconsistently
used and really don't need to be separate utility functions.
A key part of the motivation here is to work towards making more
of the tests more self-contained and less reliant on the common
test harness where possible.
PR-URL: https://github.com/nodejs/node/pull/56712
Reviewed-By: Yagiz Nizipli <yagiz@nizipli.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Since `common/crypto` already exists, it makes sense to keep
crypto-related utilities there. The only exception being
common.hasCrypto which is needed up front to determine
if tests should be skipped.
Eliminate the redundant check in hasFipsCrypto and just
use crypto.getFips() directly where needed.
PR-URL: https://github.com/nodejs/node/pull/56714
Reviewed-By: Yagiz Nizipli <yagiz@nizipli.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Adds a debug-only macro that can be used to track when a V8 fast API is
called. A map of counters is maintained in in thread-local storage and
an internal API can be called to get the total count associated with
a call id.
Specific tests are added and `crypto.timingSafeEqual` as well as
internal documentation are updated to show how to use the macro
and test fast API calls without running long loops.
PR-URL: https://github.com/nodejs/node/pull/54317
Reviewed-By: Robert Nagy <ronagy@icloud.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Yagiz Nizipli <yagiz@nizipli.com>
Reviewed-By: Tobias Nießen <tniessen@tnie.de>
Using a direct approach to create the readline async iterator
allowed an iteration over 20 to 58% faster.
**BREAKING CHANGE**: With that change, the async iteterator
obtained from the readline interface doesn't have the
property "stream" any longer. This happened because it's no
longer created through a Readable, instead, the async
iterator is created directly from the events of the readline
interface instance, so, if anyone is using that property,
this change will break their code.
Also, the Readable added a backpressure control that is
fairly compensated by the use of FixedQueue + monitoring
its size. This control wasn't really precise with readline
before, though, because it only pauses the reading of the
original stream, but the lines generated from the last
message received from it was still emitted. For example:
if the readable was paused at 1000 messages but the last one
received generated 10k lines, but no further messages were
emitted again until the queue was lower than the readable
highWaterMark. A similar behavior still happens with the
new implementation, but the highWaterMark used is fixed: 1024,
and the original stream is resumed again only after the queue
is cleared.
Before making that change, I created a package implementing
the same concept used here to validate it. You can find it
[here](https://github.com/Farenheith/faster-readline-iterator)
if this helps anyhow.
PR-URL: https://github.com/nodejs/node/pull/41276
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
These very small values can cause crashes/exceptions to occur on some
systems because most time is spent in V8 GC or in parts of node core
that are not being tested (e.g. streams).
PR-URL: https://github.com/nodejs/node/pull/31816
Reviewed-By: James M Snell <jasnell@gmail.com>
A benchmark was added but the appropriate settings were not added to
test-benchmark-buffer. These two additions make sure that the new
benchmark file only runs a single benchmark during testing.
PR-URL: https://github.com/nodejs/node/pull/29163
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Yongsheng Zhang <zyszys98@gmail.com>
Many benchmarks use test/common/tmpdir. This changes 3 benchmarks that
use NODE_TMPDIR to also use test/common/tmpdir.
This is necessary in preparation for the next commit that changes tmpdir
to delete tmpdir.path when the Node.js process exits. Thus, if multiple
benchmarks are run sequentially, the ones that use tmpdir will remove
the directory and the ones changed here would fail because it does not
exist. This happens when running test/benchmark.
Note: to explicitly select a directory for tmpdir, use NODE_TEST_DIR.
PR-URL: https://github.com/nodejs/node/pull/28858
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
