test/parallel/test-worker-http2-stream-terminate.js
#43084
Labels
async_hooks
Issues and PRs related to the async hooks subsystem.
flaky-test
Issues and PRs related to the tests with unstable failures on the CI.
Comments
RaisinTen
added
the
flaky-test
|
This flaky test causes a lot of Jenkins build failure, see nodejs/reliability#292. Can we mark this test as flaky? |
|
Temporarily marking the test flaky until someone comes up with a proper fix sounds reasonable to me given that it is causing so many CI failures. |
|
Another failure - https://ci.nodejs.org/job/node-test-binary-windows-js-suites/15103/ |
RaisinTen
added a commit
to RaisinTen/node
that referenced
this issue
Jun 14, 2022
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: nodejs#43084 Signed-off-by: Darshan Sen <raisinten@gmail.com>
|
Sent #43425 to mark the test as flaky on Windows. |
nodejs-github-bot
pushed a commit
that referenced
this issue
Jun 18, 2022
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: #43084 Signed-off-by: Darshan Sen <raisinten@gmail.com> PR-URL: #43425 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Tobias Nießen <tniessen@tnie.de>
Hi @RaisinTen the
This data is extracted from today's nodejs/reliability#315 |
@F3n67u Sounds good to me |
|
I created a pr to move |
|
cc @nodejs/async_hooks For some reason the ids don't match up Line 183 in b20838a |
RaisinTen
added
the
async_hooks
targos
pushed a commit
that referenced
this issue
Jul 12, 2022
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: #43084 Signed-off-by: Darshan Sen <raisinten@gmail.com> PR-URL: #43425 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Tobias Nießen <tniessen@tnie.de>
targos
pushed a commit
that referenced
this issue
Jul 18, 2022
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: #43084 Signed-off-by: Darshan Sen <raisinten@gmail.com> PR-URL: #43425 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Tobias Nießen <tniessen@tnie.de>
targos
pushed a commit
that referenced
this issue
Jul 31, 2022
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: #43084 Signed-off-by: Darshan Sen <raisinten@gmail.com> PR-URL: #43425 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Tobias Nießen <tniessen@tnie.de>
kvakil
added a commit
to kvakil/node
that referenced
this issue
Aug 2, 2022
These tests seem to timeout quite often. I don't know why, but one possible reason is that they are starting a lot of threads. It seems that tests in `test/parallel` are assumed to only start one thread each, so having 11 threads running at a time feels like a lot. It also seems that these tests fail in a correlated fashion: take a look at [this reliability report][]. The failures all occur on the same build machines on the same PRs. This suggests to me some sort of CPU contention. [this reliability report]: nodejs/reliability#334 On my Linux machine decreasing the parallelism & iterations here reduce the `user` time from ~11.5 seconds to ~2 seconds, depending on the test. I have seen these tests take 30-60 seconds on CI (Alpine in particular). I went back to the diffs that introduced that introduced these changes and verified that they failed at least 90% of the time with the reduced iteration count, which feels sufficient. Refs: nodejs#43499 Refs: nodejs#43084
nodejs-github-bot
pushed a commit
that referenced
this issue
Aug 5, 2022
These tests seem to timeout quite often. I don't know why, but one possible reason is that they are starting a lot of threads. It seems that tests in `test/parallel` are assumed to only start one thread each, so having 11 threads running at a time feels like a lot. It also seems that these tests fail in a correlated fashion: take a look at [this reliability report][]. The failures all occur on the same build machines on the same PRs. This suggests to me some sort of CPU contention. [this reliability report]: nodejs/reliability#334 On my Linux machine decreasing the parallelism & iterations here reduce the `user` time from ~11.5 seconds to ~2 seconds, depending on the test. I have seen these tests take 30-60 seconds on CI (Alpine in particular). I went back to the diffs that introduced that introduced these changes and verified that they failed at least 90% of the time with the reduced iteration count, which feels sufficient. Refs: #43499 Refs: #43084 PR-URL: #44090 Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com> Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
danielleadams
pushed a commit
that referenced
this issue
Aug 16, 2022
These tests seem to timeout quite often. I don't know why, but one possible reason is that they are starting a lot of threads. It seems that tests in `test/parallel` are assumed to only start one thread each, so having 11 threads running at a time feels like a lot. It also seems that these tests fail in a correlated fashion: take a look at [this reliability report][]. The failures all occur on the same build machines on the same PRs. This suggests to me some sort of CPU contention. [this reliability report]: nodejs/reliability#334 On my Linux machine decreasing the parallelism & iterations here reduce the `user` time from ~11.5 seconds to ~2 seconds, depending on the test. I have seen these tests take 30-60 seconds on CI (Alpine in particular). I went back to the diffs that introduced that introduced these changes and verified that they failed at least 90% of the time with the reduced iteration count, which feels sufficient. Refs: #43499 Refs: #43084 PR-URL: #44090 Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com> Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
ruyadorno
pushed a commit
that referenced
this issue
Aug 23, 2022
These tests seem to timeout quite often. I don't know why, but one possible reason is that they are starting a lot of threads. It seems that tests in `test/parallel` are assumed to only start one thread each, so having 11 threads running at a time feels like a lot. It also seems that these tests fail in a correlated fashion: take a look at [this reliability report][]. The failures all occur on the same build machines on the same PRs. This suggests to me some sort of CPU contention. [this reliability report]: nodejs/reliability#334 On my Linux machine decreasing the parallelism & iterations here reduce the `user` time from ~11.5 seconds to ~2 seconds, depending on the test. I have seen these tests take 30-60 seconds on CI (Alpine in particular). I went back to the diffs that introduced that introduced these changes and verified that they failed at least 90% of the time with the reduced iteration count, which feels sufficient. Refs: #43499 Refs: #43084 PR-URL: #44090 Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com> Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
targos
pushed a commit
that referenced
this issue
Sep 5, 2022
These tests seem to timeout quite often. I don't know why, but one possible reason is that they are starting a lot of threads. It seems that tests in `test/parallel` are assumed to only start one thread each, so having 11 threads running at a time feels like a lot. It also seems that these tests fail in a correlated fashion: take a look at [this reliability report][]. The failures all occur on the same build machines on the same PRs. This suggests to me some sort of CPU contention. [this reliability report]: nodejs/reliability#334 On my Linux machine decreasing the parallelism & iterations here reduce the `user` time from ~11.5 seconds to ~2 seconds, depending on the test. I have seen these tests take 30-60 seconds on CI (Alpine in particular). I went back to the diffs that introduced that introduced these changes and verified that they failed at least 90% of the time with the reduced iteration count, which feels sufficient. Refs: #43499 Refs: #43084 PR-URL: #44090 Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com> Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Fyko
pushed a commit
to Fyko/node
that referenced
this issue
Sep 15, 2022
These tests seem to timeout quite often. I don't know why, but one possible reason is that they are starting a lot of threads. It seems that tests in `test/parallel` are assumed to only start one thread each, so having 11 threads running at a time feels like a lot. It also seems that these tests fail in a correlated fashion: take a look at [this reliability report][]. The failures all occur on the same build machines on the same PRs. This suggests to me some sort of CPU contention. [this reliability report]: nodejs/reliability#334 On my Linux machine decreasing the parallelism & iterations here reduce the `user` time from ~11.5 seconds to ~2 seconds, depending on the test. I have seen these tests take 30-60 seconds on CI (Alpine in particular). I went back to the diffs that introduced that introduced these changes and verified that they failed at least 90% of the time with the reduced iteration count, which feels sufficient. Refs: nodejs#43499 Refs: nodejs#43084 PR-URL: nodejs#44090 Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com> Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
guangwong
pushed a commit
to noslate-project/node
that referenced
this issue
Oct 10, 2022
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: nodejs/node#43084 Signed-off-by: Darshan Sen <raisinten@gmail.com> PR-URL: nodejs/node#43425 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Tobias Nießen <tniessen@tnie.de>
juanarbol
pushed a commit
that referenced
this issue
Oct 10, 2022
These tests seem to timeout quite often. I don't know why, but one possible reason is that they are starting a lot of threads. It seems that tests in `test/parallel` are assumed to only start one thread each, so having 11 threads running at a time feels like a lot. It also seems that these tests fail in a correlated fashion: take a look at [this reliability report][]. The failures all occur on the same build machines on the same PRs. This suggests to me some sort of CPU contention. [this reliability report]: nodejs/reliability#334 On my Linux machine decreasing the parallelism & iterations here reduce the `user` time from ~11.5 seconds to ~2 seconds, depending on the test. I have seen these tests take 30-60 seconds on CI (Alpine in particular). I went back to the diffs that introduced that introduced these changes and verified that they failed at least 90% of the time with the reduced iteration count, which feels sufficient. Refs: #43499 Refs: #43084 PR-URL: #44090 Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com> Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
juanarbol
pushed a commit
that referenced
this issue
Oct 11, 2022
These tests seem to timeout quite often. I don't know why, but one possible reason is that they are starting a lot of threads. It seems that tests in `test/parallel` are assumed to only start one thread each, so having 11 threads running at a time feels like a lot. It also seems that these tests fail in a correlated fashion: take a look at [this reliability report][]. The failures all occur on the same build machines on the same PRs. This suggests to me some sort of CPU contention. [this reliability report]: nodejs/reliability#334 On my Linux machine decreasing the parallelism & iterations here reduce the `user` time from ~11.5 seconds to ~2 seconds, depending on the test. I have seen these tests take 30-60 seconds on CI (Alpine in particular). I went back to the diffs that introduced that introduced these changes and verified that they failed at least 90% of the time with the reduced iteration count, which feels sufficient. Refs: #43499 Refs: #43084 PR-URL: #44090 Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com> Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
|
Hey, there. I would like to investigates into this issue. Is there any recent failure? I searched in the CI system, https://github.com/nodejs/reliability/issues?q=is%3Aissue+is%3Aopen+test-worker-http2-stream-terminate, it looks like this test has paased consistently since 2022-07-15 |
I don't think it will show up in those reports now that it is marked as unreliable. I think the only way to make progress on this is to figure out how to cause the issue on your own machine or else to remove the unreliable designation in parallel.status and see if it starts causing failures again. |
I suppose we could also try running it in CI with the stress test job and have it ignore the flaky designation, treating failures as failures. |
Trott
added a commit
to Trott/io.js
that referenced
this issue
Nov 12, 2022
Trott
added a commit
to Trott/io.js
that referenced
this issue
Nov 13, 2022
guangwong
pushed a commit
to noslate-project/node
that referenced
this issue
Jan 3, 2023
These tests seem to timeout quite often. I don't know why, but one possible reason is that they are starting a lot of threads. It seems that tests in `test/parallel` are assumed to only start one thread each, so having 11 threads running at a time feels like a lot. It also seems that these tests fail in a correlated fashion: take a look at [this reliability report][]. The failures all occur on the same build machines on the same PRs. This suggests to me some sort of CPU contention. [this reliability report]: nodejs/reliability#334 On my Linux machine decreasing the parallelism & iterations here reduce the `user` time from ~11.5 seconds to ~2 seconds, depending on the test. I have seen these tests take 30-60 seconds on CI (Alpine in particular). I went back to the diffs that introduced that introduced these changes and verified that they failed at least 90% of the time with the reduced iteration count, which feels sufficient. Refs: nodejs/node#43499 Refs: nodejs/node#43084 PR-URL: nodejs/node#44090 Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com> Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
guangwong
pushed a commit
to noslate-project/node
that referenced
this issue
Jan 3, 2023
These tests seem to timeout quite often. I don't know why, but one possible reason is that they are starting a lot of threads. It seems that tests in `test/parallel` are assumed to only start one thread each, so having 11 threads running at a time feels like a lot. It also seems that these tests fail in a correlated fashion: take a look at [this reliability report][]. The failures all occur on the same build machines on the same PRs. This suggests to me some sort of CPU contention. [this reliability report]: nodejs/reliability#334 On my Linux machine decreasing the parallelism & iterations here reduce the `user` time from ~11.5 seconds to ~2 seconds, depending on the test. I have seen these tests take 30-60 seconds on CI (Alpine in particular). I went back to the diffs that introduced that introduced these changes and verified that they failed at least 90% of the time with the reduced iteration count, which feels sufficient. Refs: nodejs/node#43499 Refs: nodejs/node#43084 PR-URL: nodejs/node#44090 Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com> Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Test
test-worker-http2-stream-terminate
Platform
node-test-binary-windows-js-suites
Console output
Platform
smartos20-64
Console output
Platform
freebsd12-x64
Console output
Build links
Additional information
No response
The text was updated successfully, but these errors were encountered: