You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Platform: Unix, at least Ubuntu 18.04. The callback issue also affects Windows.
Subsystem: net
Discovered while working on #28858. I investigated this for a while but wasn't able to solve the issue. Opening this to keep track, or to get an explanation if someone knows what's going on.
There seem to be two (possibly related) issues when using a pipe with net.Server:
The pipe file descriptor is not closed (or one of them? there seems to be more than one in some cases).
This doesn't happen with all the tests that use pipes, but only with parallel/test-child-process-server-close and parallel/test-tls-wrap-econnreset-pipe. The first one passes the pipe as the stdout of a child process and the second triggers an error in the server, so this issue may be related to that and actually expected.
Calling server.close() after destroying the client connection is arguably always wrong because the server might not have processed the client-going-away event yet. It needs to act on the peer, the conn object in this test.
This issue has been open for 3 years with no movement. No one else chimed in and it's not even clear to me which node version it applied to, so... I'm going to close it.
Discovered while working on #28858. I investigated this for a while but wasn't able to solve the issue. Opening this to keep track, or to get an explanation if someone knows what's going on.
There seem to be two (possibly related) issues when using a pipe with net.Server:
The pipe file descriptor is not closed (or one of them? there seems to be more than one in some cases).
Patch to reproduce:
The callback of `server.close()` is never called.
Patch to reproduce:
This doesn't happen with all the tests that use pipes, but only with
parallel/test-child-process-server-close
andparallel/test-tls-wrap-econnreset-pipe
. The first one passes the pipe as the stdout of a child process and the second triggers an error in the server, so this issue may be related to that and actually expected.cc @bnoordhuis, @indutny, @nodejs/streams
The text was updated successfully, but these errors were encountered: