`test-inspector-multisession-ws` and `test-inspector-break-when-eval`
will be affected by an upstream bug when we upgrade V8 to 8.1. The bug
is caused when the Inspector sets a pause at the start of a function
compiled with `CompileFunctionInContext`, but that function hasn't been
executed yet.
On both tests, this issue is triggered by pausing while in C++ executing
LookupAndCompile, which is called by requiring internal modules while
running `console.log`. To eliminate this issue in both tests, we add an
extra `console.log` to ensure we only pause we required all internal
modules we need. On `test-inspector-break-when-eval`, we also need to
start the child process with `--inspect-brk` instead of `--inspect` to
ensure the test is predictable (this test would occasianlly fail on
slower machines, when console.log doesn't run fast enough to finish
after emitting `Runtime.consoleAPICalled` and before the parent process
sending `Runtime.evaluate` message.
Ref: https://bugs.chromium.org/p/v8/issues/detail?id=10287
PR-URL: https://github.com/nodejs/node/pull/32234
Refs: https://bugs.chromium.org/p/v8/issues/detail?id=10287
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Jiawen Geng <technicalcute@gmail.com>
Reviewed-By: Michaël Zasso <targos@protonmail.com>
This is only for 10.15 but this test is periodically failing across
many CI runs. Would like to mark this as flaky so we can avoid lots
of red CI.
Refs: https://github.com/nodejs/node/issues/21781
PR-URL: https://github.com/nodejs/node/pull/32189
Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com>
Reviewed-By: Beth Griggs <Bethany.Griggs@uk.ibm.com>
The process.on('exit', ...) checks duplicate the work of
`common.mustCall()` and are superfluous. Remove them.
Signed-off-by: Rich Trott <rtrott@gmail.com>
PR-URL: https://github.com/nodejs/node/pull/32120
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Robert Nagy <ronagy@icloud.com>
Rename two idnetifiers that were snake_case rather than camelCase.
Signed-off-by: Rich Trott <rtrott@gmail.com>
PR-URL: https://github.com/nodejs/node/pull/32120
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Robert Nagy <ronagy@icloud.com>
Cover an previously uncovered exception possible in the internal start
function for FSWatcher.
Signed-off-by: Rich Trott <rtrott@gmail.com>
PR-URL: https://github.com/nodejs/node/pull/32057
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Anto Aravinth <anto.aravinth.cse@gmail.com>
Remove convenience function for internal assertions. It is only used
once.
Signed-off-by: Rich Trott <rtrott@gmail.com>
PR-URL: https://github.com/nodejs/node/pull/32057
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Anto Aravinth <anto.aravinth.cse@gmail.com>
test-inspector-module is very fast and seems to be runnable at the same
time as other tests. Move from sequential directory to parallel.
PR-URL: https://github.com/nodejs/node/pull/32025
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
OpenSSL s_server accepts port 0 as an indicator to use an open port
provided by the operating system. Use that instead of common.PORT in the
test.
Remove 500ms delay added in 8e461673c4.
Hopefully the race condition in OpenSSL s_server has been fixed and/or
the change to port 0 means that the server is listening by the time
the ACCEPT text is printed and the setTimeout() is no longer necessary.
PR-URL: https://github.com/nodejs/node/pull/32024
Reviewed-By: Ben Coe <bencoe@gmail.com>
Reviewed-By: Sam Roberts <vieuxtech@gmail.com>
Remove a test that made a flawed assumption that a single
large buffer write can be interrupted by a timeout event.
PR-URL: https://github.com/nodejs/node/pull/31499
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: David Carlier <devnexen@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
When dgram socket implicit binding fails, an attempt is made to
clean up the send queue. This was originally implemented using
an 'error' handler that performed cleanup and then emitted a
fake error, which concealed the original error. This was done
to prevent cases where the same error was emitted twice. Now
that the errorMonitor event is available, use that to perform
the cleanup without impacting the actual error handling.
PR-URL: https://github.com/nodejs/node/pull/31958
Refs: https://github.com/nodejs/help/issues/2484
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
If terminating the process with ctrl-c / SIGINT, prints a JS stacktrace
leading up to the currently executing code.
The feature would be enabled under option `--trace-sigint`.
Conditions of no stacktrace on sigint:
- has (an) active sigint listener(s);
- main thread is idle (i.e. uv polling), a message instead of stacktrace
would be printed.
PR-URL: https://github.com/nodejs/node/pull/29207
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
Reviewed-By: Christopher Hiller <boneskull@boneskull.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
This completely refactors the `expectsError` behavior: so far it's
almost identical to `assert.throws(fn, object)` in case it was used
with a function as first argument. It had a magical property check
that allowed to verify a functions `type` in case `type` was passed
used in the validation object. This pattern is now completely removed
and `assert.throws()` should be used instead.
The main intent for `common.expectsError()` is to verify error cases
for callback based APIs. This is now more flexible by accepting all
validation possibilites that `assert.throws()` accepts as well. No
magical properties exist anymore. This reduces surprising behavior
for developers who are not used to the Node.js core code base.
This has the side effect that `common` is used significantly less
frequent.
PR-URL: https://github.com/nodejs/node/pull/31092
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com>
This is a following PR of #30714.
PR-URL: https://github.com/nodejs/node/pull/30819
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Add the `pskCallback` client/server option, which resolves an identity
or identity hint to a pre-shared key.
Add the `pskIdentityHint` server option to set the identity hint for the
ServerKeyExchange message.
Co-authored-by: Chris Osborn <chris.osborn@sitelier.com>
Co-authored-by: stephank <gh@stephank.nl>
Co-authored-by: Taylor Zane Glaeser <tzglaeser@gmail.com>
PR-URL: https://github.com/nodejs/node/pull/23188
Reviewed-By: Sam Roberts <vieuxtech@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
This adds colors to the passed through arguments in case the stream
supports colors. The PID will also be highlighted.
PR-URL: https://github.com/nodejs/node/pull/30930
Reviewed-By: James M Snell <jasnell@gmail.com>
ERR_INVALID_ARG_TYPE is the most common error used throughout the
code base. This improves the error message by providing more details
to the user and by indicating more precisely which values are allowed
ones and which ones are not.
It adds the actual input to the error message in case it's a primitive.
If it's a class instance, it'll print the class name instead of
"object" and "falsy" or similar entries are not named "type" anymore.
PR-URL: https://github.com/nodejs/node/pull/29675
Reviewed-By: Rich Trott <rtrott@gmail.com>
The test was using fixed timeouts and that seems to be causing sporadic
test failures on pi1-docker host (which is a very slow machine.)
Fixes: https://github.com/nodejs/node/issues/30828
PR-URL: https://github.com/nodejs/node/pull/30834
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com>
Reviewed-By: Gabriel Schulhof <gabriel.schulhof@intel.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
This commit replaces common.busyLoop() with sleep().
PR-URL: https://github.com/nodejs/node/pull/30787
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Gus Caplan <me@gus.host>
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
The resolution for the main entry point may fail when the resolution
requires a preloaded module to be executed first (for example when
adding new extensions to the resolution process). Silently skipping
such failures allow us to defer the resolution as long as needed
without having any adverse change (since the main entry point won't
resolve anyway if it really can't be resolved at all).
PR-URL: https://github.com/nodejs/node/pull/30336
Reviewed-By: Guy Bedford <guybedford@gmail.com>
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
Use block-scoping in test-net-server-address. This also allows us to
easily rename some identifiers that were not camelCase.
PR-URL: https://github.com/nodejs/node/pull/30754
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Now that the test uses an open port assigned by the operating system
rather than a hardcoded common.PORT, it can be moved to parallel.
PR-URL: https://github.com/nodejs/node/pull/30749
Reviewed-By: Denys Otrishko <shishugi@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Change common.PORT to arbitrary port in
test-child-process-fork-getconnections to prepare for moving that test
from sequential to parallel.
PR-URL: https://github.com/nodejs/node/pull/30749
Reviewed-By: Denys Otrishko <shishugi@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
test-http-max-http-headers seems to run fine in parallel, even with
`tools/test.py -j 96 --repeat 192
test/parallel/test-http-max-http-headers.js`.
The same applies to `test-set-http-max-http-headers.js` which (as
written) depends on `test-http-max-http-headers.js` being in the same
directory. So that is being moved too.
PR-URL: https://github.com/nodejs/node/pull/30712
Reviewed-By: David Carlier <devnexen@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
In test-http-max-http-headers, a comment asks why we are subtracting 32
from the length of the invalid-length-by-1 headers instead of just 1.
Subtracting 1 seems to be correct and works.
PR-URL: https://github.com/nodejs/node/pull/30712
Reviewed-By: David Carlier <devnexen@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Use an array literal instead of using split() on a very short string.
PR-URL: https://github.com/nodejs/node/pull/30712
Reviewed-By: David Carlier <devnexen@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Upcoming lint rule will require a blank line between consecutive
functions. Add it in the places where we don't have it already.
PR-URL: https://github.com/nodejs/node/pull/30696
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com>
Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com>
Reviewed-By: Gus Caplan <me@gus.host>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Denys Otrishko <shishugi@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Change the test to be robust in slow environments and move to parallel.
The previous version of the test failed for me in parallel with just two
or four simultaneous versions running. This version passes 96
simultaneous versions running, but still fails as designed if the
request writes fail to prevent the request timeout from occurring.
PR-URL: https://github.com/nodejs/node/pull/30677
Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Applying platformTimeout() to the interval is counterproductive. It
should be applied to the request timeout duration only.
PR-URL: https://github.com/nodejs/node/pull/30677
Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
test-http-server-consumed-timeout has code to that causes it to be
skipped on busy machines. Instead, use an exponential backoff for the
timeout if the machine is busy.
PR-URL: https://github.com/nodejs/node/pull/30677
Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
test-inspector-contexts may be entering an infinite loop (or very
long-running loop) in CI, resulting in flakiness. Or maybe not. Add
logging to find out.
PR-URL: https://github.com/nodejs/node/pull/30649
Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com>
Reviewed-By: Anto Aravinth <anto.aravinth.cse@gmail.com>
Reviewed-By: Denys Otrishko <shishugi@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
As I'm working with this test, I'm finding the destructuring of assert
and vm to make this test harder to read/understand. So I'm taking the
liberty of removing them.
PR-URL: https://github.com/nodejs/node/pull/30649
Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com>
Reviewed-By: Anto Aravinth <anto.aravinth.cse@gmail.com>
Reviewed-By: Denys Otrishko <shishugi@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
If session.post() generates an error, it is currently ignored. Add check
for error by adding a callback to session.post() invocation.
PR-URL: https://github.com/nodejs/node/pull/30649
Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com>
Reviewed-By: Anto Aravinth <anto.aravinth.cse@gmail.com>
Reviewed-By: Denys Otrishko <shishugi@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
In test-inspector-contexts, if mainContextPromise is modified such that
the `method` argument is changed to something invalid, the test still
passes and the second part of the test never runs. Use
`common.mustCall()` to cause the test to fail if the second part of the
test does not run.
Refs: https://github.com/nodejs/node/issues/30519#issuecomment-558476839
PR-URL: https://github.com/nodejs/node/pull/30649
Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com>
Reviewed-By: Anto Aravinth <anto.aravinth.cse@gmail.com>
Reviewed-By: Denys Otrishko <shishugi@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
The message argument of two test functions in
test-inspector-async-call-stack is useful but unused. Use it!
PR-URL: https://github.com/nodejs/node/pull/30618
Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Yongsheng Zhang <zyszys98@gmail.com>
Reviewed-By: Tobias Nießen <tniessen@tnie.de>
I don't believe there's a reason test-stream-writable-clear-buffer needs
to be in sequential. Move it to parallel.
PR-URL: https://github.com/nodejs/node/pull/30561
Reviewed-By: Denys Otrishko <shishugi@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
This reveals the values that cause the assertion error, should it
happen.
PR-URL: https://github.com/nodejs/node/pull/30561
Reviewed-By: Denys Otrishko <shishugi@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Replace setTimeout() with setImmediate() in
test-stream-writable-clear-buffer. The test still fails in Node.js 8.6.0
(if you comment out the `common` module, since it uses BigInts and those
aren't supported in 8.6.0).
PR-URL: https://github.com/nodejs/node/pull/30561
Reviewed-By: Denys Otrishko <shishugi@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
On certain platforms, updating V8 to 7.9 made the numbers a bit higher
than the current limit.
PR-URL: https://github.com/nodejs/node/pull/30020
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Jiawen Geng <technicalcute@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
