Errors from decoder/encoder not handled properly

Describe the bug Socket.io-client does not handle errors thrown by default parser “socket.io-parser”. When parser throws an error, there is no event fired (disconnected, connect_error, etc). The worst case scenario is if you have a binary data being transfered and the decoder has “this.reconstructor” set to true, but receives a string for some reason… the connection goes into limbo state and never recovers.

This does not happen when using for example msgpack parser since it does not throw any errors at all. Also this does not seem to be an issue with socker.io-parser since its completely legit that the parser throws an error.

To Reproduce You can manually throw an error in manager.js where “this.decoder.add(data);” line is and watch that you don’t get any error emitted, but the console still shows the error.

Socket.IO client version: 4.5.1

Expected behavior Disconnect the socket on decoder error, emit an error and auto-reconnect. Also this seems to be fixed in socket.io server code - the decoder.add part is wrapped with try/catch block

Platform:

• Device: iPhone 13 Pro Max
• OS: ios 15.6.1 running on Angular PWA (safari engine)

Additional context Actual real life scenario when this happens: Angular PWA app running on iPhone … socketio connection receives mpeg-ts binary data. The binary data is split into two packets, the decoder tries to reconstruct it. When you swipe away from the application, system will put app to sleep in about a few seconds without disconnecting the socket. When the application wakes up, the connection is lost and socket is reconnected, however the decoder still might expect binary data (having this.reconstructor flag set to true) and throws an error “got plaintext data when reconstructing a packet” which is not handled by socket.io properly and the connection stalls. Unfortunately forceNew flag has no effect in pwa app since the object is not re-created when app wakes up.

[darrachequesne]

This should be fixed by https://github.com/socketio/socket.io-client/commit/2403b88057bf3fd32eb2047c82be26c455c13a2f, included in version 4.5.3.

[mhio]

The error handler added in https://github.com/socketio/socket.io-client/commit/c5970231699aa47b00c4a617af4239d0fa90fa53 is masking regular errors in socket.on('x') functions for me too.

Why is the caught error e being discarded? The close/disconnect sounds a valid mechanism but can the e be emitted as an error? or least be attached to the close reason?

Although in the broader sense, the change introduced to the default error handling behaviour might not be just a point release.