-
Notifications
You must be signed in to change notification settings - Fork 29.1k
-
Notifications
You must be signed in to change notification settings - Fork 29.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
async-hooks.test-writewrap
is flaky
#54809
Comments
Reproducible locally (macOS ARM), looks like it's a native issue (
|
I get no failures on macOS
|
FWIW I can't reproduce on Linux x64:
Maybe it has to do with the amount of memory available? |
I think with many of these timeout tests we should consider moving them into the sequential suite to see if that helps |
@lpinca ... we don't have to actually land the PR. I want to determine if moving the test would make it less flaky which can be done with a PR and a few stress test runs. The PR doesn't actually have to land. That said, we have to get the CI back to a point where we aren't having to do 10-15 CI runs on a PR just to get it landed. If that means we freeze all development on everything else until CI is green again, let's do that. |
Ofc it will, it will not trigger the issue... The stress test CI does not run the test in parallel.
Let's start by fixing the issues with the macOS machines which is what actually blocked development. |
@jasnell try this
or
I think that if we find the reason why the process sometimes hangs we will be able to fix the timeout issue for many tests. |
I can't do anything about the macOS machines right now. I can work on investigating these timeouts, which is what I'm trying to do.
Has that been tested? If so, can you point out where? |
Going through the |
Running some local tests on
So far this is the only variable that I've been able to identify that reliably alters the rate of timeout on this particular test. The reason for choosing 65550 is that it is fairly close (but still over the default high water mark for the stream. Setting the highwatermark to 65600 appears to reduce the rate of timeout when using 65600 as the allocation size. This makes me think that the tests that are timing out are due to some intersection between v8 GC and streams backpressure management -- I'm unable to reproduce any timeouts for any allocations smaller than the default high water mark size. |
@jasnell in my environment the issue seems different, see #52959 (comment). |
Test
async-hooks.test-writewrap
Platform
Linux x64
Console output
Build links
Additional information
No response
The text was updated successfully, but these errors were encountered: