It is flaky due to the same cause of test-child-process-pipe-dataflow
being flaky - cygwin quirks - so skip it on Windows too.
Drive-by: remove the skip mark of test-child-process-pipe-dataflow
in the status file and directly skip it in the test with a comment.
PR-URL: https://github.com/nodejs/node/pull/49621
Reviewed-By: Debadree Chatterjee <debadree333@gmail.com>
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: LiviaMedeiros <livia@cirno.name>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Moshe Atlow <moshe@atlow.co.il>
This is constantly failing on Windows now that the CI is never green
there. To give CI at least some green space, mark it as SKIP, because
we've been practically ignoring the failure for months anyway, and
will probably just continue doing that.
PR-URL: https://github.com/nodejs/node/pull/49563
Refs: https://github.com/nodejs/node/issues/48300
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Moshe Atlow <moshe@atlow.co.il>
Reviewed-By: Michaël Zasso <targos@protonmail.com>
This test is flaky on ARM with V8 >= 11.2.
Skip it so we can update V8 before the release of Nodejs 20.0.0.
PR-URL: https://github.com/nodejs/node/pull/47299
Refs: https://github.com/nodejs/node/pull/47251
Reviewed-By: Filip Skokan <panva.ip@gmail.com>
Reviewed-By: Jiawen Geng <technicalcute@gmail.com>
Reviewed-By: Tobias Nießen <tniessen@tnie.de>
Reviewed-By: Richard Lau <rlau@redhat.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Yagiz Nizipli <yagiz@nizipli.com>
There is a race condition where process.kill can be sent before the
target is ready to receive the signal.
Fixes: https://github.com/nodejs/node/issues/41123
PR-URL: https://github.com/nodejs/node/pull/45354
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
Reviewed-By: Tobias Nießen <tniessen@tnie.de>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
As a consequence of https://github.com/nodejs/node/issues/43014 ,
server sockets and others, once connected, report string family
names. But when feeding these to Socket.connect(), it passes
these to host resolution with a string for family while a numeric
family is expected internally. This results in wrong hints flags
to be set and resolution to fail.
As solution, is to add ability to handle both numeric and string
family names when doing lookup and connect.
Fixes: https://github.com/nodejs/node/issues/44003
PR-URL: https://github.com/nodejs/node/pull/44083
Reviewed-By: Paolo Insogna <paolo@cowtech.it>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
The test is causing a lot of CI failures, so I'd say that we should mark
this test flaky until someone comes up with a proper fix.
Refs: https://github.com/nodejs/node/issues/43084
Signed-off-by: Darshan Sen <raisinten@gmail.com>
PR-URL: https://github.com/nodejs/node/pull/43425
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Tobias Nießen <tniessen@tnie.de>
The corresponding issue was closed 3 months ago and it has apparently
been a long time since the failure has been seen in CI.
Refs: https://github.com/nodejs/node/issues/28803
PR-URL: https://github.com/nodejs/node/pull/42045
Reviewed-By: Mestery <mestery@protonmail.com>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Tobias Nießen <tniessen@tnie.de>
Reviewed-By: James M Snell <jasnell@gmail.com>
Correct the names of two tests that have been marked `FLAKY` on IBM i
so they will actually be marked as such by the test runner.
Refs: https://github.com/nodejs/node/pull/41812
Refs: https://github.com/nodejs/node/issues/39683
PR-URL: https://github.com/nodejs/node/pull/41984
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Mestery <mestery@protonmail.com>
Reviewed-By: Beth Griggs <bgriggs@redhat.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Michael Dawson <midawson@redhat.com>
Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com>
Refs: https://github.com/nodejs/node/issues/39683
These are being worked, but we really should have
marked flaky a long time ago in ordert to make
then nightlies non-red.
Signed-off-by: Michael Dawson <mdawson@devrus.com>
PR-URL: https://github.com/nodejs/node/pull/41812
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Richard Lau <rlau@redhat.com>
Reviewed-By: Mohammed Keyvanzadeh <mohammadkeyvanzade94@gmail.com>
Refs: https://github.com/nodejs/node/issues/41201
From recent reliability reports this is now the most
common failure by far in CI runs. Mark the test as
flaky until the issue is resolved.
Signed-off-by: Michael Dawson <mdawson@devrus.com>
PR-URL: https://github.com/nodejs/node/pull/41533
Reviewed-By: Ben Coe <bencoe@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Refs: https://github.com/nodejs/node/issues/41123
- This is one of the remaining high occurance flaky
tests from the reliability reports and recent
failures in the CI. Mark as flaky until issue
is resolved under referenced issue.
Signed-off-by: Michael Dawson <mdawson@devrus.com>
PR-URL: https://github.com/nodejs/node/pull/41302
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Refs: https://github.com/nodejs/node/issues/41206
This test seems to be failing regularly on
windows with a timeout. Mark it slow to reduce
CI noise until it gets investigated.
Signed-off-by: Michael Dawson <mdawson@devrus.com>
PR-URL: https://github.com/nodejs/node/pull/41207
Reviewed-By: Richard Lau <rlau@redhat.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
test-worker-message-port-transfer-terminate was fixed in
25447d82d3 but the status file was not updated to reflect this.
PR-URL: https://github.com/nodejs/node/pull/37633
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: Richard Lau <rlau@redhat.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
The test hasn't failed in a long time as far as I can tell. The issue
may have been fixed by various event updates/changes to http2 and
related systems.
PR-URL: https://github.com/nodejs/node/pull/37461
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
* Use a copy of plaintext to prevent tampering of the original
* Since subtle.decrypt returns a Promise containing an ArrayBuffer and
ArrayBuffers cannot be modified directly, create a Buffer from it
right away so that the modification in the next line works as intended
Fixes: https://github.com/nodejs/node/issues/35586
PR-URL: https://github.com/nodejs/node/pull/37380
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Myles Borins <myles.borins@gmail.com>
Some tests are marked SKIP,FLAKY (resulting in yellow/unstable CI when
they fail) and others are marked SKIP (which means the results don't
affect CI at all). There doesn't seem to be any reason for the
difference. Mark them all as SKIP as IBM i for consistency and to have
the luxury of a green daily CI. We'll want these to be at least
SKIP,FLAKY (and preferably not skipped at all) before IBM i is
supported.
PR-URL: https://github.com/nodejs/node/pull/37035
Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Per rvagg:
```
Persistent failure, even after restarts of the whole cluster. #36478 was
merged into this test yesterday but the parent commit still has the
failures.
What has changed is the Docker version. They all got an upgrade to
5:20.10.2~3-0~raspbian-buster and this is all running inside containers.
It's going to be the newest version of Docker running in our CI and I
wonder whether we're going to see similar failures when we upgrade other
hosts or if this is going to be restricted to ARM.
Other than that, I'm not sure what this could be. It seems like a
straightforward test that shouldn't fail, maybe Docker has introduced
something new for unprivileged port binding inside containers?
```
Signed-off-by: James M Snell <jasnell@gmail.com>
PR-URL: https://github.com/nodejs/node/pull/36850
Refs: https://github.com/nodejs/node/issues/36847
Reviewed-By: Michael Dawson <midawson@redhat.com>
Reviewed-By: Mary Marchini <oss@mmarchini.me>
The test has not failed in quite some time (as far as I can tell) on CI.
Optimistically removing it.
Refs: https://github.com/nodejs/node/pull/29889
PR-URL: https://github.com/nodejs/node/pull/36496
Reviewed-By: Gerhard Stöbich <deb2001-github@yahoo.de>
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Remove flaky designation for test-worker-eventlooputil fixed in 9dbde1d.
PR-URL: https://github.com/nodejs/node/pull/35961
Reviewed-By: Richard Lau <rlau@redhat.com>
Reviewed-By: Yongsheng Zhang <zyszys98@gmail.com>
Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com>
Reviewed-By: Gerhard Stöbich <deb2001-github@yahoo.de>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
This is consistently failing in CI right now. Lets mark it flaky
while we figure out what is going on.
Refs: https://github.com/nodejs/node/issues/35844
PR-URL: https://github.com/nodejs/node/pull/35886
Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com>
Reviewed-By: Stephen Belanger <admin@stephenbelanger.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Ricky Zhou <0x19951125@gmail.com>
This is now failing inconsistently across many platforms. This
appears to be the result of the addition of mustSucceed being
added to the test during testing refactoring.
We should mark flaky until we have figured out what the issue
is.
Refs: https://github.com/nodejs/node/issues/35881
PR-URL: https://github.com/nodejs/node/pull/35883
Reviewed-By: Tobias Nießen <tniessen@tnie.de>
Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com>
Due to some unknown system configuration, the code
`socket_ipv6.bind(0, 111::1)` does not throw the
expected error EADDRNOTAVAIL on some IBM i systems.
This issue is still being investigated. To get the
IBM i CI passing, skip it for now.
PR-URL: https://github.com/nodejs/node/pull/34209
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
The test is marked flaky on ARM because it times out on Raspberry Pi
devices in CI. Split the single test file into four separate test files
to ease debugging. Add fs.close() to avoid timing out.
Fixes: https://github.com/nodejs/node/issues/33796
PR-URL: https://github.com/nodejs/node/pull/34203
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Robert Nagy <ronagy@icloud.com>
Issuing a shutdown() on IBM i PASE with parameter SHUT_WR
also sends a normal close sequence to the partner program.
This leads to timing issues and ECONNRESET failures in some
test cases.
Refs: https://github.com/libuv/libuv/pull/2782
PR-URL: https://github.com/nodejs/node/pull/34118
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: Beth Griggs <Bethany.Griggs@uk.ibm.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Test name test-worker-message-port-message-before-close is too long for
a commit message description.
Refs: https://github.com/nodejs/node/issues/31280
PR-URL: https://github.com/nodejs/node/pull/32849
Refs: https://github.com/nodejs/node/issues/28803
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: Juan José Arboleda <soyjuanarbol@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Refs: https://github.com/nodejs/node/issues/28803
PR-URL: https://github.com/nodejs/node/pull/32849
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: Juan José Arboleda <soyjuanarbol@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
This test is somewhat regularly flaky on 12.x and it appears master as
well. There appears to be an issue tracking flakes for 6+ months. Seems
reasonable to mark this to keep us from having red CI.
Refs: https://github.com/nodejs/node/issues/29802
PR-URL: https://github.com/nodejs/node/pull/32595
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Alternative to https://github.com/nodejs/node/pull/31590.
It appears that the issue here is that the test falsely assumed that
closing the client (which also currently destroys the socket rather
than gracefully shutting down the connection) would still leave
enough time for the server side to receive the stream error.
Address that by explicitly waiting for the server side to receive the
stream error before closing the client and the connection with it.
Refs: https://github.com/nodejs/node/pull/31590
Refs: https://github.com/nodejs/node/issues/20750
PR-URL: https://github.com/nodejs/node/pull/31610
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Denys Otrishko <shishugi@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
test-crypto-keygen and test-crypto-dh-stateless are currently flaky
on ARM CI systems due to their slow CPUs.
PR-URL: https://github.com/nodejs/node/pull/31178
Reviewed-By: Sam Roberts <vieuxtech@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>
On some platforms the `'end'` event might not be emitted because the
socket could be destroyed by the other peer while the client is still
sending the data triggering an error. Use the `'close'` event instead.
PR-URL: https://github.com/nodejs/node/pull/30360
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com>
Reviewed-By: Anto Aravinth <anto.aravinth.cse@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
The test has not failed on FreeBSD in the last 100 runs and appears to
perhaps not be an issue anymore.
Closes: https://github.com/nodejs/node/issues/23089
test-gc-http-client-onerror: PASS,FLAKY
PR-URL: https://github.com/nodejs/node/pull/28429
Fixes: https://github.com/nodejs/node/issues/23089
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Sam Roberts <vieuxtech@gmail.com>
Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Address a race condition in the test; the Worker’s exit events
may have been not recorded because the Worker exited before
the listeners were attached.
Fix the by attaching the event listeners before telling the Worker
to exit.
PR-URL: https://github.com/nodejs/node/pull/28307
Fixes: https://github.com/nodejs/node/issues/28299
Fixes: https://github.com/nodejs/node/issues/28106
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Yongsheng Zhang <zyszys98@gmail.com>
Due to a bug in V8 GC, this test case has to potential to fail
on all platforms. V8 master has been patched with a fix and waiting
for it to be backported to V8 7.5 and 7.6. Skipping the test until
it is backported. Bug can be tracked here:
https://bugs.chromium.org/p/v8/issues/detail?id=9333
PR-URL: https://github.com/nodejs/node/pull/28175
Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: Refael Ackermann (רפאל פלחי) <refack@gmail.com>
Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
PR-URL: https://github.com/nodejs/node/pull/28123
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Beth Griggs <Bethany.Griggs@uk.ibm.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Also try to make more traceable.
PR-URL: https://github.com/nodejs/node/pull/28035
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Reviewed-By: Sam Roberts <vieuxtech@gmail.com>
The TLS trace data is best-effort, and enough can be dropped from pipe
buffers that only the start of the trace is detected. Only assert on the
first line of the trace, it should not get dropped, and it's enough to
check that trace was enabled via CLI.
PR-URL: https://github.com/nodejs/node/pull/28043
Fixes: https://github.com/nodejs/node/issues/27636
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
These tests should be fixed now.
PR-URL: https://github.com/nodejs/node/pull/27705
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
`socket.destroy()` can destory the stream before the chunk to write
with `socket.end()` is actually sent. Furthermore `socket.destroy()`
destroys `p` and not the actual raw socket. As a result it is possible
that the connection is left open.
Remove `socket.destroy()` to ensure that the chunk is sent. Also use
`common.mustCall()` to ensure that the `'secureConnection'` and
`'secureConnect'` events are emitted exactly once.
PR-URL: https://github.com/nodejs/node/pull/27478
Fixes: https://github.com/nodejs/node/issues/26938
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Sam Roberts <vieuxtech@gmail.com>
Reviewed-By: Fedor Indutny <fedor.indutny@gmail.com>
