[mkantautas]

If the writable side of a stream returned by createWebSocketStream() is ended and the socket is destroyed before it emits 'finish', the _final() callback is never called. This happens when the other peer does not answer the close frame and the close timer destroys the socket, or when the connection is reset. The stream never emits 'finish' or 'close' and is never destroyed, so pipeline() never calls its callback.

const { pipeline, Readable } = require('stream');
const { WebSocket, WebSocketServer, createWebSocketStream } = require('ws');

const wss = new WebSocketServer({ port: 0 }, () => {
  const ws = new WebSocket(`ws://localhost:${wss.address().port}`, {
    closeTimeout: 1000
  });
  const duplex = createWebSocketStream(ws);

  duplex.resume();
  pipeline(Readable.from(['foo']), duplex, (err) => {
    console.log('pipeline callback', err); // Never called.
  });
});

wss.on('connection', (ws) => {
  ws.pause(); // Never answer the close frame.
});

This makes _final() also listen for the 'close' event of the socket. The listener is prepended so that 'finish' is still emitted before 'end' and the existing 'end' listener destroys the stream. Without that, the (2/2) test fails on Node.js >= 16. If the stream is being destroyed, the callback is not called, so pipeline() still reports the error passed to duplex.destroy().

#2338 is related. It handles the case where the socket is already destroyed when _final() is called, and does not fix this one, where the socket is destroyed while _final() waits for 'finish'.

[lpinca]

As with #2338 once the Duplex has been created, you should work with it rather than the underlying socket. Cases were the closing handshake does not complete cleanly should be handled by finding inactive connections and calling duplex.destroy() on them. The stream should not be allowed to terminate cleanly and implicitly, as if everything had proceeded successfully (it did not finish).