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>
Re-evaluating an errored ESM should lead to rejecting
the rejection again - this is also the case when importing
it twice. In the case of retrying with
require after import, just throw the cached error.
Drive-by: add some debug logs.
PR-URL: https://github.com/nodejs/node/pull/58957
Fixes: https://github.com/nodejs/node/issues/58945
Reviewed-By: Marco Ippolito <marcoippolito54@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
The comment in the test file stated that:
"SIMD is not supported on rhel8-ppc64le"
This is incorrect -- WASM SIMD support is dependent on the available
instructions, not the operating system. So it is more correct to say
that WASM SIMD is not supported on IBM Power8 architecture.
PR-URL: https://github.com/nodejs/node/pull/58767
Reviewed-By: Ethan Arrowood <ethan@arrowood.dev>
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: Juan José Arboleda <soyjuanarbol@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Darshan Sen <raisinten@gmail.com>
When --import is used, the ESM loader is used to handle even pure
CJS entry points, and it can run into CJS module facades in the
evaluating state when the parent CJS module is being evaluated.
In this case it should be allowed, since the ESM <-> CJS cycles
that are meant to be disallowed (for the time being) should
already be detected before evaluation and wouldn't get here,
and CJS <-> CJS cycles are fine.
PR-URL: https://github.com/nodejs/node/pull/58598
Fixes: https://github.com/nodejs/node/issues/58515
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Ethan Arrowood <ethan@arrowood.dev>
Split indirect eval import tests as they depends on the JS stack to
resolve the referrer.
PR-URL: https://github.com/nodejs/node/pull/58637
Reviewed-By: Jacob Smith <jacob@frende.me>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Underlying issues still need to be investigated
but this will prevent these failures from failing
the daily builds.
Timeouts:
- parallel.test-http-proxy-fetch
- parallel.test-https-proxy-fetch
- benchmark.test-benchmark-websocket
- parallel.test-inspector-network-fetch
- es-module.test-wasm-web-api
- parallel.test-fetch
- parallel.test-without-async-context-frame
- report.test-report-exclude-network
Flaky test:
- parallel.test-process-cpuUsage
PR-URL: https://github.com/nodejs/node/pull/58583
Refs: https://github.com/nodejs/node/issues/58582
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
Reviewed-By: Richard Lau <rlau@redhat.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
By default, the `readableWebStream` method of `FileHandle` returns
a ReadableStream that, when finished, does not close the underlying
FileHandle. This can lead to issues if the stream is consumed
without having a reference to the FileHandle to close after use.
This commit adds an `autoClose` option to the `readableWebStream`
method, which, when set to `true`, will automatically close the
FileHandle when the stream is finished or canceled.
The test modified in this commit demonstrates one of the cases where
this is necessary in that the stream is consumed by separate code than
the FileHandle which was being left to close the underlying fd when
it is garbage collected, which is a deprecated behavior.
PR-URL: https://github.com/nodejs/node/pull/58548
Reviewed-By: LiviaMedeiros <livia@cirno.name>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Boolean value to check if an ES Module is the entrypoint of the
current process.
Implements: #57226
Co-authored-by: Antoine du Hamel <duhamelantoine1995@gmail.com>
PR-URL: https://github.com/nodejs/node/pull/57804
Fixes: https://github.com/nodejs/node/issues/57226
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Guy Bedford <guybedford@gmail.com>
Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
Reviewed-By: Marco Ippolito <marcoippolito54@gmail.com>
PR-URL: https://github.com/nodejs/node/pull/56491
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
Reviewed-By: Jacob Smith <jacob@frende.me>
PR-URL: https://github.com/nodejs/node/pull/57704
Reviewed-By: Jacob Smith <jacob@frende.me>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
fix listeners registered via `process.on('exit', ...` not receiving
error code 13 when an unsettled top-level-await is encountered in
the code
PR-URL: https://github.com/nodejs/node/pull/56872
Fixes: https://github.com/nodejs/node/issues/53551
Reviewed-By: Yagiz Nizipli <yagiz@nizipli.com>
Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
PR-URL: https://github.com/nodejs/node/pull/57290
Reviewed-By: Richard Lau <rlau@redhat.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Michaël Zasso <targos@protonmail.com>
PR-URL: https://github.com/nodejs/node/pull/56628
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Geoffrey Booth <webadmin@geoffreybooth.com>
Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
- Improve the error message that shows up when there is a race
from doing require(esm) and import(esm) at the same time.
- Improve error message of ERR_REQUIRE_ASYNC_MODULE by showing
parent and target file names, if available.
Drive-by: split the require(tla) tests since we are modifying
the tests already.
PR-URL: https://github.com/nodejs/node/pull/57126
Refs: https://github.com/fisker/prettier-issue-17139
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
Reviewed-By: Chengzhong Wu <legendecas@gmail.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>
Previously this PR it was expected that InternalWorker
usage doesn't require the --allow-worker when the permission
model is enabled. This, however, exposes a vulnerability
whenever the instance gets accessed by the user. For example
through diagnostics_channel.subscribe('worker_threads')
PR-URL: https://github.com/nodejs-private/node-private/pull/629
Refs: https://hackerone.com/reports/2575105
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Robert Nagy <ronagy@icloud.com>
CVE-ID: CVE-2025-23083
Move permission model from 1.1 (Active Development)
to 2.0 (Stable).
PR-URL: https://github.com/nodejs/node/pull/56201
Reviewed-By: Yagiz Nizipli <yagiz@nizipli.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>
Reviewed-By: Marco Ippolito <marcoippolito54@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Stephen Belanger <admin@stephenbelanger.com>
require(esm) is relatively stable now and the experimental warning
has run its course - it's now more troublesome than useful.
This patch changes it to no longer emit a warning unless
`--trace-require-module` is explicitly used. The flag supports
two modes:
- `--trace-require-module=all`: emit warnings for all usages
- `--trace-require-module=no-node-modules`: emit warnings for
usages that do not come from a `node_modules` folder.
PR-URL: https://github.com/nodejs/node/pull/56194
Fixes: https://github.com/nodejs/node/issues/55417
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
Reviewed-By: Yagiz Nizipli <yagiz@nizipli.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Geoffrey Booth <webadmin@geoffreybooth.com>
Reviewed-By: Marco Ippolito <marcoippolito54@gmail.com>
Reviewed-By: Rafael Gonzaga <rafael.nunu@hotmail.com>
PR-URL: https://github.com/nodejs/node/pull/56183
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
Reviewed-By: Jacob Smith <jacob@frende.me>
Previously the implemention of require(esm) only converted the
rejected promise from module evaluation into an error, but the
rejected promise was still treated as a pending unhandled
rejection by the promise rejection callback, because the promise
is created by V8 internals and we don't get a chance to mark
it as handled, so the rejection incorrectly marked as unhandled
would still go through unhandled rejection handling (if no
global listener is set, the default handling would print a warning
and make the Node.js instance exit with 1).
This patch fixes it by calling into the JS promise rejection
callback to mark the evalaution rejection handled so that
it doesn't go through unhandled rejection handling.
PR-URL: https://github.com/nodejs/node/pull/56122
Fixes: https://github.com/nodejs/node/issues/56115
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Reviewed-By: Chemi Atlow <chemi@atlow.co.il>
As part of the standard experimental feature graduation
policy, when we unflagged require(esm) we moved the
experimental warning to be emitted when require() is
actually used to load ESM, which previously was an error.
However, some packages in the ecosystem have already
being using try-catch to load require(esm) to e.g.
resolve optional dependency, and emitting warning from
there instead of throwing directly could break the CLI
output.
To reduce the disruption for releases, as a compromise, this
patch skips the warning if require(esm) comes from
node_modules, where users typically don't have much control
over the code. This warning will be eventually removed
when require(esm) becomes stable.
This patch was originally intended for the LTS releases,
though it seems there's appetite for it on v23.x as
well so it's re-targeted to the main branch.
PR-URL: https://github.com/nodejs/node/pull/55960
Refs: https://github.com/nodejs/node/pull/55217
Refs: https://github.com/nodejs/node/issues/52697
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
Reviewed-By: Jacob Smith <jacob@frende.me>
This tracks the asynchronicity in the ModuleWraps when they turn out to
contain TLA after instantiation, and throw the right error
(ERR_REQUIRE_ASYNC_MODULE) when it's required again. It removes
the freezing of ModuleWraps since it's not meaningful to freeze
this when the rest of the module loader is mutable, and we
can record the asynchronicity in the ModuleWrap right after
compilation after we get a V8 upgrade that contains
v8::Module::HasTopLevelAwait() instead of searching through
the module graph repeatedly which can be slow.
PR-URL: https://github.com/nodejs/node/pull/55520
Fixes: https://github.com/nodejs/node/issues/55516
Refs: https://github.com/nodejs/node/issues/52697
Reviewed-By: Paolo Insogna <paolo@cowtech.it>
Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
Reviewed-By: Chengzhong Wu <legendecas@gmail.com>
Reviewed-By: Jacob Smith <jacob@frende.me>
Trim off irrelevant internal stack frames for require(esm) warnings
so it's easier to locate where the call comes from when
--trace-warnings is used.
PR-URL: https://github.com/nodejs/node/pull/55496
Reviewed-By: Marco Ippolito <marcoippolito54@gmail.com>
Reviewed-By: Paolo Insogna <paolo@cowtech.it>
When a ESM module cannot be loaded by require due to the presence
of TLA, its module status would be stopped at kInstantiated. In
this case, when it's imported again, we should allow it to be
evaluated asynchronously, as it's also a common pattern for users
to retry with dynamic import when require fails.
PR-URL: https://github.com/nodejs/node/pull/55502
Fixes: https://github.com/nodejs/node/issues/55500
Refs: https://github.com/nodejs/node/issues/52697
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Chemi Atlow <chemi@atlow.co.il>
When emitting the experimental warning for `require(esm)`, include
information about the parent module and the module being require()-d
to help users locate and update them.
PR-URL: https://github.com/nodejs/node/pull/55397
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Stephen Belanger <admin@stephenbelanger.com>
Reviewed-By: Chemi Atlow <chemi@atlow.co.il>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Chengzhong Wu <legendecas@gmail.com>
