| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
| assert.strictEqual('ECONNREFUSED', e.code); | ||
| })); | ||
| server.close(); | ||
| server.close(() => { |
There was a problem hiding this comment.
This test seems a bit racey in general. If you wait for the server to close, couldn't another process potentially take the port?
Sorry, something went wrong.
There was a problem hiding this comment.
@cjihrig Hmm... You're right.
I think better is move test-net-connect-handle-econnrefused.js to test/sequential.
If this test run sequentially, another test cannot take the port, right?
Sorry, something went wrong.
There was a problem hiding this comment.
I would stick to having it be in parallel and seeing if this fixes it. We need less tests in sequential, not more, as they take a really long time to run.
Sorry, something went wrong.
There was a problem hiding this comment.
LGTM. The test itself is racy but at least this change make it somewhat less racy...
Sorry, something went wrong.
| assert.strictEqual('ECONNREFUSED', e.code); | ||
| })); | ||
| server.close(); | ||
| server.close(() => { |
There was a problem hiding this comment.
Can you wrap this in common.mustCall?
Sorry, something went wrong.
There was a problem hiding this comment.
@joyeecheung It would be nice. I'll fix it.
Sorry, something went wrong.
Sorry, something went wrong.
|
I agree with @cjihrig, this does not fix potential race conditions that could happen if another process grabs the port before the close() callback is invoked. |
Sorry, something went wrong.
|
In general I agree that we need less tests in sequential but having a racy test is bad as well. We should probably have a look at our sequential tests in general. I am going to open a meta issue for that. @apapirovski are you good with this for now? |
Sorry, something went wrong.
|
Am I holding this up? I approved this as is, with no changes or nits. My comments was re: keeping it in parallel which it is. I don't think I should be the blocker? If there's concerns, I would suggest running a stress test with -j 96 --repeat 192 perhaps and seeing what comes back? |
Sorry, something went wrong.
|
My point was that I actually think it is better to be on the safe side right now. Our CI is really bad at the moment because we have so many flakes and it would be great to reduce those. Working on the sequential ones at a different time to reduce those would for me be the better approach. |
Sorry, something went wrong.
|
Stress test CI: https://ci.nodejs.org/job/node-stress-single-test/1776/ and running one locally. If either doesn't pass then we should move to sequential. No failures locally after many runs but the stress test job is always more flaky so that should ultimately decide. |
Sorry, something went wrong.
PR-URL: nodejs#18257 Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com> Reviewed-By: Michaël Zasso <targos@protonmail.com> Reviewed-By: Anatoli Papirovski <apapirovski@mac.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
PR-URL: #18257 Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com> Reviewed-By: Michaël Zasso <targos@protonmail.com> Reviewed-By: Anatoli Papirovski <apapirovski@mac.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
PR-URL: #18257 Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com> Reviewed-By: Michaël Zasso <targos@protonmail.com> Reviewed-By: Anatoli Papirovski <apapirovski@mac.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
PR-URL: nodejs#18257 Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com> Reviewed-By: Michaël Zasso <targos@protonmail.com> Reviewed-By: Anatoli Papirovski <apapirovski@mac.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
PR-URL: #18257 Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com> Reviewed-By: Michaël Zasso <targos@protonmail.com> Reviewed-By: Anatoli Papirovski <apapirovski@mac.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
PR-URL: #18257 Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com> Reviewed-By: Michaël Zasso <targos@protonmail.com> Reviewed-By: Anatoli Papirovski <apapirovski@mac.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
PR-URL: #18257 Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com> Reviewed-By: Michaël Zasso <targos@protonmail.com> Reviewed-By: Anatoli Papirovski <apapirovski@mac.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
PR-URL: #18257 Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com> Reviewed-By: Michaël Zasso <targos@protonmail.com> Reviewed-By: Anatoli Papirovski <apapirovski@mac.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
The port used in the test could be taken by another process before the callback of `server.close()` is called. Move it to sequential. Refs: nodejs#18257 (comment) Fixes: nodejs#26907
The port used in the test could be taken by another process before the callback of `server.close()` is called. Move it to sequential. PR-URL: nodejs#27014 Fixes: nodejs#26907 Refs: nodejs#18257 (comment) Reviewed-By: Rich Trott <rtrott@gmail.com> Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
The port used in the test could be taken by another process before the callback of `server.close()` is called. Move it to sequential. PR-URL: #27014 Fixes: #26907 Refs: #18257 (comment) Reviewed-By: Rich Trott <rtrott@gmail.com> Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
| Back | FazBrowse Home | New Git URL |
This PR closes #18164
I changed timing of connecting to server.
It connects to server after server.close called certainly.
Does that solve this issue?
I'd appreciate any feedback or suggestions.
Checklist
Affected core subsystem(s)
test