-
Notifications
You must be signed in to change notification settings - Fork 29.6k
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
test: fix flaky test-net-error-twice #4342
Conversation
On Windows there can exist some race condition where the notification of the client's `socket.destroy()` isn't received before the server writes to the socket. This race condition was more evident/reproducible on a single core system. This commit fixes the flakiness by waiting until the server's connection event handler has been called to destroy the client socket and perform the server socket write. Fixes: nodejs#4057
Stress test: https://ci.nodejs.org/job/node-stress-single-test/191/nodes=win2012r2/ |
Works for me if it works for the others who have been looking at this: As I said in the other issue, I'd still like to know the mechanism by which adding |
LGTM |
LGTM The fact that this failed so reliably on Windows 2012 alone still worries me, together with the apparent interference with console. |
On Windows there can exist some race condition where the notification of the client's `socket.destroy()` isn't received before the server writes to the socket. This race condition was more evident/reproducible on a single core system. This commit fixes the flakiness by waiting until the server's connection event handler has been called to destroy the client socket and perform the server socket write. Fixes: #4057 PR-URL: #4342 Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By: João Reis <reis@janeasystems.com>
Landed in 4b0b991. |
On Windows there can exist some race condition where the notification of the client's `socket.destroy()` isn't received before the server writes to the socket. This race condition was more evident/reproducible on a single core system. This commit fixes the flakiness by waiting until the server's connection event handler has been called to destroy the client socket and perform the server socket write. Fixes: nodejs#4057 PR-URL: nodejs#4342 Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By: João Reis <reis@janeasystems.com>
On Windows there can exist some race condition where the notification of the client's `socket.destroy()` isn't received before the server writes to the socket. This race condition was more evident/reproducible on a single core system. This commit fixes the flakiness by waiting until the server's connection event handler has been called to destroy the client socket and perform the server socket write. Fixes: nodejs#4057 PR-URL: nodejs#4342 Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By: João Reis <reis@janeasystems.com>
On Windows there can exist some race condition where the notification of the client's `socket.destroy()` isn't received before the server writes to the socket. This race condition was more evident/reproducible on a single core system. This commit fixes the flakiness by waiting until the server's connection event handler has been called to destroy the client socket and perform the server socket write. Fixes: #4057 PR-URL: #4342 Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By: João Reis <reis@janeasystems.com>
On Windows there can exist some race condition where the notification of the client's `socket.destroy()` isn't received before the server writes to the socket. This race condition was more evident/reproducible on a single core system. This commit fixes the flakiness by waiting until the server's connection event handler has been called to destroy the client socket and perform the server socket write. Fixes: #4057 PR-URL: #4342 Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By: João Reis <reis@janeasystems.com>
On Windows there can exist some race condition where the notification of the client's `socket.destroy()` isn't received before the server writes to the socket. This race condition was more evident/reproducible on a single core system. This commit fixes the flakiness by waiting until the server's connection event handler has been called to destroy the client socket and perform the server socket write. Fixes: nodejs#4057 PR-URL: nodejs#4342 Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By: João Reis <reis@janeasystems.com>
On Windows there can exist some race condition where the OS notification of the client's
socket.destroy()
isn't received before the server writes to the socket, so the OS happily writes to the server socket and thesocket.destroy()
notification is seen as an EOF. This race condition was more evident/reproducible on a single core system (for obvious reasons in hindsight).This commit fixes the flakiness by waiting until the server's connection event handler has been called to destroy the client socket and perform the server socket write.
Fixes: #4057