TCP socket emits error after close

[tufosa]

• Version: v12.18.0
• Platform: Linux 4.15.0-96-generic Makefile: Avoid running find in a non-existent directory #97-Ubuntu SMP Wed Apr 1 03:25:46 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
• Subsystem: net, streams

What steps will reproduce the bug?

This might not be a bug itself, but just some missing details in the documentation. The documentation about TCP sockets claim 2 things:

1. No more events are emitted after a close event (this is claimed in Writable streams)
2. A close event is always emitted after an error event (this is claimed in net.Socket

There seems to be an edge case (writing into the socket after the close event) where both claims fail. To reproduce it, you will need to:

1. Start a listener: node listener.js

// listener.js code
const net = require('net');                                
                                    
const server = net.createServer();                                
                                                
server.on('connection', socket => {                                 
  console.info('NEW SOCKET');                                
  socket.setEncoding('utf8');                                
  socket.on('data', data => console.info('DATA: ', data));                      
  socket.on('end', () => console.info('END'));                   
  socket.on('close', () => console.log('CLOSE'));                             
  socket.on('error', err => console.log('ERROR: ', err));                       
});                                                              
                                                                                
server.listen({host: '127.0.0.1', port: 1100});

2. Start a sender: node sender.js

// sender.js code
const net = require('net');                                                                                                              
                                                                                
const socket = net.createConnection({host: '127.0.0.1', port: 1100});                                                                       
                                                            
socket.on('end', () => console.info('END'));                                    
socket.on('close', () => {                                                  
  console.info('CLOSE');
  socket.write('SOCKET CLOSE');
});                                                                             
socket.on('error', err => console.log('ERROR: ', err));

3. Kill (ctrl+c) the listener process.
4. Check that the CLOSE trace was written before the ERROR trace in the sender console.

I understand that you are not supposed to write in a socket after having received the close event, so this behavior might not be a bug, but it might require some changes in the docs.

I came across this behavior because it happened in one of our node.js applications in production and I was assuming in my code that error events could never come after close events. Of course, the real case was not as obvious as the example provided, and it was way trickier.

[mmomtchev]

write() to an already closed socket results in SIGPIPE (or it returns EPIPE if the SIGPIPE is explicitly ignored by the process - which Node does), so this behavior is consistent with the traditional BSD sockets behavior

[ronag]

Is this still a problem in v14? We did a lot of fixes related to this kind of things.

[tufosa]

@mmomtchev that's why I suggest that this issue might not be a bug, but some missing details in the documentation. The docs claim 2 things (see the description of the issue) and none of them is fulfilled in this example.

@ronag I've just performed the experiment using node v14.13.1 and the results seem to be the same

[mmomtchev]

@ronag This is the second similar question that I see, what should be the correct behavior of Node in this case? Is Node supposed to completely mask ECONNRESET and EPIPE from the user code?

[ronag]

'error' should not be emitted after 'close'.

[mmomtchev]

So write after 'close' should be ignored silently?

[ronag]

So write after 'close' should be ignored silently?

The callback would still provide an error, but yes, no errors should be emitted.

[mmomtchev]

There's no 'error' event on master, but there is on 12.x and 14.x