Run supported DH, ECDH, legacy TLS, TLS 1.2 PSK, cipher metadata,
raw key, and X.509 date cases with BoringSSL. Assert its DH flags,
curve format errors, and name-constraint behavior. Narrow key/cert
array exclusions to the failing multi-identity cases.
Use modp5 for the DH group setter checks and remove the unused legacy
protocol fallback helper.
Signed-off-by: Filip Skokan <panva.ip@gmail.com>
Assisted-by: Codex
PR-URL: https://github.com/nodejs/node/pull/66922
Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Add zlib.crc32c(data[, value]), which computes the CRC-32C checksum
(Castagnoli polynomial, RFC 3720 section 12.1). CRC-32C has better
error detection properties than the CRC-32 of zlib.crc32() and is the
checksum required by many current protocols, formats and services,
among them:
- iSCSI header and data digests (RFC 7143)
- SCTP packet checksums (RFC 9260)
- iWARP MPA framing (RFC 5044)
- NVMe/TCP header and data digests
- ext4, Btrfs and XFS metadata checksums
- the Snappy framing format
- Apache Kafka record batches
- LevelDB and RocksDB block checksums
- TensorFlow TFRecord files
- Google Cloud Storage and Amazon S3 object checksums
Implementing any of these in JavaScript currently needs a userland
CRC-32C, which is far slower than native code.
The function mirrors zlib.crc32(): it accepts a string (encoded as
UTF-8) or an ArrayBufferView, takes an optional 32-bit unsigned
starting value so a checksum can be continued across chunks, and has a
V8 fast API path.
The checksum is computed by absl::ExtendCrc32c() from the bundled
Abseil, which is already built and linked into node, so this adds no
new dependency and no new checksum implementation. absl_crc32c is
added to the libraries linked with --shared-abseil.
Abseil selects its hardware-accelerated CRC-32C path (SSE4.2 and
PCLMULQDQ on x64, the CRC32 and PMULL extensions on arm64) at compile
time, so with node's default compiler flags the portable table-driven
implementation is used. It runs at about the same speed as zlib.crc32()
(about 6.5 GB/s on a recent x64 machine), while the hardware path
reaches about 38 GB/s. Builds whose target CPU baseline already
includes those instructions get the hardware path without changes.
Enabling it for generic builds is left out on purpose: on x64, Abseil
uses the accelerated code for unrecognized CPUs without a runtime
feature check, so compiling it in unconditionally would fault on CPUs
without SSE4.2.
Signed-off-by: Philipp Dunkel <pip@pipobscure.com>
PR-URL: https://github.com/nodejs/node/pull/66828
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Paolo Insogna <paolo@cowtech.it>
Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com>
The C++ option parser treats `_` and `-` as the same character in
option names, so `--watch_path` is the same as `--watch-path`.
Watch mode compared spellings literally when it removed its own flags
from `process.execArgv` and `NODE_OPTIONS` before spawning the child.
The underscore spellings got through, so each child went back into
watch mode and spawned another child, and the application never ran.
Normalize option names before comparing them. Forward the original
arguments to the child unchanged.
Signed-off-by: Trivikram Kamat <16024985+trivikr@users.noreply.github.com>
Assisted-by: claude:opus-5.5
PR-URL: https://github.com/nodejs/node/pull/66365
Fixes: https://github.com/nodejs/node/issues/66364
Reviewed-By: Moshe Atlow <moshe@atlow.co.il>
When stripping watch flags, NODE_OPTIONS is tokenized and rejoined
for the child process. Values were only re-quoted if they contained
a space, and nothing inside the quotes was escaped. A value with a
double quote made the child fail with "unterminated string", and a
backslash inside a quoted value was silently dropped.
Quote values that contain a space or a double quote, and escape
backslashes and double quotes inside the quotes, so the child
tokenizes the string back to the same values.
Signed-off-by: Trivikram Kamat <16024985+trivikr@users.noreply.github.com>
Assisted-by: claude:opus-5.5
PR-URL: https://github.com/nodejs/node/pull/66363
Fixes: https://github.com/nodejs/node/issues/66362
Reviewed-By: Moshe Atlow <moshe@atlow.co.il>
Putting a time limit on a Node.js process is common in many
use cases, but each of the common approaches are generally
flawed.
OS and CI timeouts are inconsistent and blind. Every OS flavor
handles process timeouts in different ways. Stock macOS and
Windows do not ship coreutils `timeout`, etc. None of the options
can explain why the process was still running or what exactly
was interrupted. Using setTimeout only fires when the event loop
is free so it misses busy loops and thread blocks and cannot
see the stack. Diagnostics triggered by signal have the same
problem.
This introduces a `--process-timeout` that should work
consistently across all runtimes. A native watchdog thread
interrupts the main thread, even in the middle of running
code. It prints the JavaScript stack (if any) and resources
keeping the event loop alive (if any), and can optionally
print a full diagnostic report. The process exits with a
distinct code (124). If the main thread is stuck in native
code, the process still exits.
$ node --process-timeout=10s -e "while(true) {}"
(node:483970) Process timed out after 10s (--process-timeout). Exiting with code 124.
Main thread was executing JavaScript:
at [eval]:1:1
at runScriptInThisContext (node:internal/vm:219:10)
at node:internal/process/execution:485:12
at [eval]-wrapper:6:24
at runScriptInContext (node:internal/process/execution:483:60)
at evalFunction (node:internal/process/execution:317:30)
at evalTypeScript (node:internal/process/execution:329:3)
at node:internal/main/eval_string:71:3
No resources keeping the event loop alive were found.
Signed-off-by: James M Snell <jasnell@gmail.com>
Assisted-by: Opencode
PR-URL: https://github.com/nodejs/node/pull/66138
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com>
The cpu-prof tests hand-rolled a partial version of what
test/common/child_process already provides: log the child's stderr
when the status is non-zero, then assert the status. That manual
version never shows stdout, the signal, or the command that ran, so
a CI failure gives less information than the helper would.
Replace those blocks with spawnSyncAndExitWithoutError(). Every
existing expectation is preserved -- status 0 is still required, and
signal null is now checked as well, matching the helper defaults.
Only success-path blocks whose assertions map one-to-one onto the
helper defaults are converted.
Refs: https://github.com/nodejs/node/pull/65351
Refs: https://github.com/nodejs/node/pull/65552
Assisted-by: claude:opus-5
Signed-off-by: Junhwan Choi <devjunsday@gmail.com>
PR-URL: https://github.com/nodejs/node/pull/65694
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Use isolated directories for the NODE_OPTIONS watch paths to avoid
recursively watching the repository's source and test trees. Allow a
platform-scaled 10 seconds for startup and restarts.
Remove the flaky markers for test-watch-mode and
test-watch-mode-inspect. The inspector restart race was already fixed
in f2aaf63846.
Signed-off-by: Filip Skokan <panva.ip@gmail.com>
Assisted-by: Codex
PR-URL: https://github.com/nodejs/node/pull/66232
Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
Reviewed-By: Moshe Atlow <moshe@atlow.co.il>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewing the performance of http tests in the smartos
CI runs revealed that a handful of HTTP related tests
are running way longer than they should, with some hitting
upwards of 66 seconds!
- Ten HTTP/HTTPS tests now close connections
deterministically instead of waiting 66 seconds.
- Two HTTP/2 tests use an explicit 64KiB stream window
and 3MB payload, while restoring timeout assertions.
- Estimated SmartOS CI saving: about 4.5 minutes at -j4.
Signed-off-by: James M Snell <jasnell@gmail.com>
Assisted-by: Opencode
PR-URL: https://github.com/nodejs/node/pull/65926
Reviewed-By: Filip Skokan <panva.ip@gmail.com>
Reviewed-By: Tim Perry <pimterry@gmail.com>
The previous deflake of this test, #63390, gave the two restart
waits common.platformTimeout(10_000) and left the first restart()
on the helper's 1000 ms default. That first call is the one still
timing out on CI.
It is also the call that needs the budget most. --watch spawns a
child process to run the script, so reaching the first Completed
running costs two process startups, while the later restarts pay for
one. Wrapping the default in platformTimeout() would not have been
enough on its own: none of its multipliers reaches a factor of ten,
so the budget would still be 1000 ms on these jobs, or 2000 ms in a
debug build.
Give that call the budget the other two already ask for, stated once in
the default rather than three times. The timer bounds how long the test
waits for watch mode to make progress, it is not an assertion about
restart latency, and the assertions on stdout and stderr are untouched.
The same helper is duplicated in test-watch-mode.mjs, with the same
default and nine call sites that take it. That file has carried
PASS, FLAKY since #44898, which is why only this one surfaces in the
reliability reports.
Signed-off-by: Christian Aurich <christian.aurichzm@gmail.com>
PR-URL: https://github.com/nodejs/node/pull/65623
Refs: https://github.com/nodejs/node/pull/63390
Refs: https://github.com/nodejs/reliability/blob/main/reports/2026-08-18.md
Refs: https://github.com/nodejs/reliability/blob/main/reports/2026-08-20.md
Refs: https://github.com/nodejs/reliability/blob/main/reports/2026-08-21.md
Refs: https://github.com/nodejs/node/issues/44898
Reviewed-By: Filip Skokan <panva.ip@gmail.com>
Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
The test verified ipv6Only by connecting to the IPv4 side of an
ephemeral port and expecting ECONNREFUSED, but it never reserved that
IPv4 port. Under parallel execution another test could occupy it,
making the connection succeed instead of being refused.
Run the test sequentially with a fixed common.PORT so it no longer
competes with other tests for the same port, matching the fix already
applied to the sibling cluster variants.
Fixes: https://github.com/nodejs/node/issues/64172
Signed-off-by: sangwook <rewq5991@gmail.com>
PR-URL: https://github.com/nodejs/node/pull/64173
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
A `.js` file with no `"type"` in the nearest package.json has no format
of its own, and `defaultGetFormat()` reports it as null. `--check`
passed that null straight to `wrapSafe()`, which parses as CommonJS.
Module syntax makes that parse bail out early, so the file was reported
as valid and `--check` exited 0 even though it is not valid JavaScript
under either goal.
At load time the goal for such a file is decided by looking for module
syntax in the source. Decide it the same way here, so the file is
parsed as a module and its real syntax error is reported. Files whose
format is known are unaffected, as are ambiguous files without module
syntax, which are still parsed as CommonJS.
Fixes: https://github.com/nodejs/node/issues/65202
Signed-off-by: Paul Bouchon <mail@bitpshr.net>
PR-URL: https://github.com/nodejs/node/pull/65203
Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
Reviewed-By: Aviv Keller <me@aviv.sh>
Promote DEP0195 from documentation-only to a runtime deprecation.
Calling node:http constructors without `new` now emits DEP0195 via
deprecateInstantiation. This covers Agent, Server, OutgoingMessage,
IncomingMessage, ServerResponse, and ClientRequest.
Update in-tree tests that called Server/Agent without `new` to use
the keyword, and add a dedicated DEP0195 coverage test.
Refs: https://github.com/nodejs/node/pull/58518
Assisted-by: Grok
Signed-off-by: Yagiz Nizipli <yagiz@nizipli.com>
PR-URL: https://github.com/nodejs/node/pull/64853
Reviewed-By: Aviv Keller <me@aviv.sh>
Reviewed-By: Tim Perry <pimterry@gmail.com>
Reviewed-By: Gürgün Dayıoğlu <hey@gurgun.day>
Reviewed-By: Filip Skokan <panva.ip@gmail.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Every unconnected send(), and the implicit bind on first send,
resolved the destination through dns.lookup() even when it was
already a literal IP. The address resolves to itself, so the call is
redundant, and tools that instrument dns.lookup() record a lookup for
every datagram sent to an IP.
Skip the resolver for a literal IP of the socket's family and report
it on the next tick, keeping dns.lookup()'s asynchronous contract. A
custom lookup function is still consulted for every address.
Refs: https://github.com/DataDog/dd-trace-js/issues/2984
Signed-off-by: Ruben Bridgewater <ruben@bridgewater.de>
PR-URL: https://github.com/nodejs/node/pull/64133
Reviewed-By: Bryan English <bryan@bryanenglish.com>
Reviewed-By: Gürgün Dayıoğlu <hey@gurgun.day>
Reviewed-By: James M Snell <jasnell@gmail.com>
Add a samplePerIteration option to monitorEventLoopDelay that records
event loop delay from libuv event loop iterations instead of the timer
interval sampler. The default remains interval-based; existing uses of
monitorEventLoopDelay() keep behaving the same unless the
samplePerIteration option is passed through.
Signed-off-by: Pablo Erhard <pablo.erhardhernandez@datadoghq.com>
PR-URL: https://github.com/nodejs/node/pull/62935
Reviewed-By: Bryan English <bryan@bryanenglish.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: James M Snell <jasnell@gmail.com>
Cancel any pending FilesWatcher debounce timer when watch mode clears
its watchers. This prevents a queued change event from restarting the
watched process after shutdown has started.
Keep the watched child exit handling attached for the lifetime of the
child so overlapping restart and shutdown paths do not remove each
other's exit listeners.
Signed-off-by: Kamat, Trivikram <16024985+trivikr@users.noreply.github.com>
Assisted-by: openai:gpt-5.5
PR-URL: https://github.com/nodejs/node/pull/63383
Reviewed-By: Tim Perry <pimterry@gmail.com>
Decided to take a short break from the work on QUIC
to implement a DTLS API. Very experimental at this
point but the basic API is there (inspired by the
QUIC API work).
The implementation is based on OpenSSL's built-in
DTLS support and no other dependencies are required.
DTLS is a datagram-based version of TLS that is used
for things like WebRTC and CoAP. It provides similar
security guarantees as TLS but is designed to work over
UDP instead of TCP.
This shouldn't be considered ready for production
but it is a good starting point for experimentation
and feedback.
```bash
./configure --experimental-dtls
make -j{nproc}
./node --experimental-dtls my-dtls-app.js
```
Signed-off-by: James M Snell <jasnell@gmail.com>
Assisted-by: Opencode:Opus 4.6
PR-URL: https://github.com/nodejs/node/pull/63182
Fixes: https://github.com/nodejs/node/issues/61630
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Stephen Belanger <admin@stephenbelanger.com>
Reviewed-By: Rafael Gonzaga <rafael.nunu@hotmail.com>
This test randomly times out (~120s) on CI due to a race condition
between child-process restart (triggered by touching the watched file)
and the second inspector-session connection.
The old code used an interval-based restart (write every 500ms) and
a 'gettingDebuggedPid' flag to pause writes during a session. This
still left a race window where getDebuggedPid() would attempt to
connect the inspector via HTTP GET /json/list + WebSocket upgrade
either before the new child was ready (empty target list) or after
the old session was being destroyed, causing the promise to hang.
Fix: Replace the interval with a single write that triggers exactly
one restart, then wait for the restarted child's 'safe to debug now'
stdout line before connecting the second inspector session. This
eliminates the race by ensuring the new child process and its
inspector session are fully ready before any connection attempt.
Removes the now-unused gettingDebuggedPid flag and the pending
setTimeout delay that was needed as a backstop for the interval.
Fixes: https://github.com/nodejs/node/issues/44898
Signed-off-by: Matteo Collina <hello@matteocollina.com>
PR-URL: https://github.com/nodejs/node/pull/63361
Reviewed-By: Moshe Atlow <moshe@atlow.co.il>
Reviewed-By: Paolo Insogna <paolo@cowtech.it>
Currently, --watch mode only tracks dependencies from the main
module graph (require/import). Worker thread entry points created
via new Worker() are not included, so changes to worker files do
not trigger restarts.
This change hooks into Worker initialization and registers the
worker entry file with watch mode, ensuring restarts when worker
files change.
Fixes: https://github.com/nodejs/node/issues/62275
Signed-off-by: SudhansuBandha <sudhansu9.vssut@gmail.com>
PR-URL: https://github.com/nodejs/node/pull/62368
Reviewed-By: Moshe Atlow <moshe@atlow.co.il>
Filip Skokan