WebSocket-Node
WebSocket-Node copied to clipboard
ECONNRESET random crash
I've solving this crash for a quite long time. pretty hard to trace.
my env: ubuntu 16.04 x64 node10 websocket 1.0.31, using WebSocketServer autoAcceptConnections=true problem: random crash on error ECONNRESET , at TCP.onread(net.js: 656:25)
out applicantion runs on mobile robot running all day&night . crash happen randomly in some weeks or month
I've checked your code. Here is my guess:
when a new client is autoAccepted, a WebSocketConnection is created. it remove all error hander of socket at the end of constructor (WebSocketConnection.js line 140 ). However it didn't install a error handler immediately , which I think is the reason for crash.
In code WebSocketRequest.js line 450, it seems event listeners are installed after a success response write. If socket error happens between that , the app crash.
Makes sense. Can you create a PR?
#408
I commented in the pull request noting that the proposed fix does work, however, I also thought I'd mention that this error can be handled from the application code by attaching an error listener to the underlying ConnectionRequest socket:
wsServer.on('request', (connectionRequest) => { connectionRequest.socket.on('error', (err) => { console.log(err); }); });
Obviously a fix implemented in the library itself is preferable in the long term.
this isn't doing anything, now we just log the error twice
Hello, is there any plan to merge this into the library? We are using 1.0.34 on nodejs v16.18.1 and occasionally seeing the ECONNRESET error (and causing a crash)
Error: write ECONNRESET
at WriteWrap.onWriteComplete [as oncomplete] (node:internal/stream_base_commons:94:16)
at TLSWrap.writeAsciiString (
I think @alin1771 is correct that this patch does not do anything because between the time when the error listeners are removed and the websocket error listeners added there is no async code so isn't it impossible for an uncaught error to occur until the next tick? However, I'm not a node expert..
All good and agreed. We put an error listener on the request.socket that catches the error.