Investigate flaky test-http-destroyed-socket-write2

[Trott]

• win2012r2

[Trott]

Stress test to see if flakiness is detectable via stress test: https://ci.nodejs.org/job/node-stress-single-test/89/nodes=win2012r2/

[Trott]

Closing #4064, #4065, and #4066. All three tests were flaky in the same CI build/run on just win2012r2, but have never been flaky before. Stress test runs on all three tests did not produce any test failures. Chalking this up to something weird that probably happened inside CI itself just this one time.

/cc @nodejs/build in case it's something they want to investigate (but totally get it if no one really wants to go down that rabbit hole right now or ever).

[BridgeAR]

I am reopening this one, since it started to fail a couple of times recently.

@ronag could you have a look?

https://ci.nodejs.org/job/node-test-commit-osx/34333/nodes=osx1014/testReport/junit/(root)/test/parallel_test_http_destroyed_socket_write2/

[BridgeAR]

Stress test: https://ci.nodejs.org/job/node-stress-single-test/74/

[ronag]

EDIT: This was an incorrect analysis

This test looks invalid. The failure is hitting a valid path as far as I can see. ERR_STREAM_DESTROYED should probably be added to the list of possible errors...

There is no guarantee that Socket will detect an ungraceful disconnect and emit 'error'. _http_server is not doing anything as far as I can see to detect a premature close on the OutgoingMessage, i.e. onServerResponseClose just waits for socket 'close' and doesn't check whether is has been ended or not.

i.e. the OutgoingMessage is not guaranteed to emit 'error' which is what the test seems to assume... though it probably should... but that's a separate issue?

[BridgeAR]

@ronag would you be so kind and open a PR to fix that? That would be great!