Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is the delay necessary?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@bnoordhuis Concise-but-naive answer: Without the delay, the test is flaky on Windows 2012 r2 on the CI infrastructure.
Less concise and marginally less naive: In this test,
conn.write(buf)is supposed to get an error (eitherEPIPEorECONNRESETdepending on timing).Unfortunately, on Windows 2012 r2 only, it appears that the call toUPDATE: Actually, I think the problem is that the client connection and server connection callbacks fire in an unpredictable order. On Windows 2012 r2 only, theclient.destroy()often returns before the socket is set to emit the error.conn.write()would often not trigger an error and the result wasassert.equal(errs.length, 1)firing (becauseerrs.lengthis 0). I triedsetImmediate()and that may have improved things but it did not resolve the flakiness. Using the timeout resolved the flakiness. (I did not experiment with a timeout of less than 100 milliseconds.)As for the cause of this on Windows 2012 r2, I don't know and would certainly be receptive to some guidance on figuring it out (or someone simply doing the work and identifying the source of the issue). Operating system limitation? Bug in libuv? Bug in
socket.destroy? I don't know. I don't have easy access to a Windows 2012 r2 machine. (I could try to run one via VirtualBox, but my laptop resources are kind of limited right now and my weak excuse is that it would probably fill up my disk.)