Description
Would it be possible to not have this fail silently and/or disconnect with a specific unload reason? We use a socket as a heartbeat to clients and we formerly used the window unload event to fire off an intentional close of the socket to inform our server when it could begin cleaning up in-memory artifacts of the client sooner (rather than waiting for our socket disconnected retry timeouts to handle cleanup).
Describe the solution you'd like
Make the socket's beforeunload silent close either configurable/disable-able or make the "silent" close emit a disconnect with a new reason.
Describe alternatives you've considered
As it stand now, we would have to either offload this server side cleanup logic to a custom endpoint (somewhat defeating one of the reasons we use sockets in the first place) or add our own event listener to beforeunload to try to emit the intentional close before the silent close occurs (which will probably lead to race conditions?). Realistically, this is currently just preventing us from bumping our socket.io version past 3.1.1