ConnectionStateRecovery not working when switching from wifi to 4g

[plok1412]

Hi all,

I'm trying to implement connection state recovery so that on instances of temporary network failure such as switching from wifi to 4g, the user will still receive the missed events during that time. However I'm bumping into the issue where upon reconnection, socket.recovered seems to be false, whereas I expect it to be true.

I am using socket.io v4.7.4 with the in memory adaptor and options:
connectionStateRecovery: { maxDisconnectionDuration: 5 * 60 * 1000, skipMiddlewares: true, }

Socket.io-client is v4.7.2 with options:
{ transports: ['websocket', 'polling'], reconnection: true }.

What I'm seeing is that when I switch networks, on the client side it'll register 'disconnect' event with reason 'transport close' immediately. However, on server side the socket does not disconnect. Now when the network is successfully switched, client starts reconnecting with the same pid as the initial connection, which server receives in the 'connection' event. At this point, if I check socket.recovered, the value is false. I believe this is because the reconnection occurs before the old socket is disconnected.

However, from reading the documentation, it seems that this use case of switching networks should be covered by the connection state recovery feature. I've looked through the source code and it also seems to only add the connection state recovery for a socket upon the socket disconnection.

Would anyone have any ideas of what might be going wrong and how to achieve the desired behaviour?

Thanks a lot! Appreciate any input.

[darrachequesne]

Hi!

I believe this is because the reconnection occurs before the old socket is disconnected.

I think you are right, the server is not aware of the disconnection yet.

What we could maybe do when restoring the session is to check if the ID exists, send some dummy packet over the connection to trigger the disconnection, and then try to restore the session.

Source here:

socket.io/packages/socket.io-adapter/lib/in-memory-adapter.ts

Lines 445 to 448 in 7427109

	override restoreSession(
	pid: PrivateSessionId,
	offset: string,
	): Promise<Session> {

What do you think?

[nootheroptions]

Hey Damien!

That sounds like a good idea! But I am a bit confused on how exactly to implement that. From looking at the SessionAwareAdapter class, there doesn't seem to be a way to link the SocketId from the Adaptor class to the PrivateSessionId in the SessionAwareAdapter class to check the ID exists.

Unless you were thinking something more like before calling restoreSession, it would see if the socket exists and then send the dummy packet to trigger the disconnect before hitting restoreSession. However with that, I don't currently have any great ideas to make sure the timing executes reliably so that it definitely disconnects before restoreSession.

Is this a feature that you would be looking to add? I'm also happy to give it a go and put up a PR, but I might need a bit of guidance on the above. Sorry if I misunderstood anything in the code that led me to the wrong idea.

[darrachequesne]

From looking at the SessionAwareAdapter class, there doesn't seem to be a way to link the SocketId from the Adaptor class to the PrivateSessionId in the SessionAwareAdapter class to check the ID exists.

Hmm yes you're right, I think we'd either have to store the relationship between sid and pid, or loop through all the connected sockets.

For clustered adapters like the one based on Redis, we would also have to make sure the session does not exist on another node.

However with that, I don't currently have any great ideas to make sure the timing executes reliably so that it definitely disconnects before restoreSession.

If we have access to the socket object, we could listen to the "disconnect" event (persistSession() would have to be awaited here), or abort after a given delay.

That being said, the connection state recovery feature was designed from the beginning as a best effort mechanism, I'm not sure whether the added complexity would be worth it.

[nootheroptions]

That being said, the connection state recovery feature was designed from the beginning as a best effort mechanism, I'm not sure whether the added complexity would be worth it.

You make a good point, I wasn't too sure if it would be worth the added complexity either. I think I will implement it using application code instead.

Thanks for the help!