Unfortunately it seems that the callback is fired way later (multiple minutes) on desktop devices. We are aware of the various server side socket configuration settings, but for us it’s unclear which setting we need to adjust.
Hey Robin, currently we delegate to the underlying TCP stack for network disconnects on the socket in the JS client. This will result in a varying amount of time before the callback is fired depending on the browser/OS.We don’t currently have an ETA for when we add this at our JS SDK level.
Thanks for the release. We’ve implemented this a couple of days ago. We do indeed now get a successful callback when a user is disconnect. However, this is taking ~ 20 seconds. We think this is due to one of the server side settings, but these are a bit unclear for us.
Which settings should we change to achieve a disconnect message within a few (3-5) seconds?
It seems the socket.onDisconnect callback function is called very late. But we do see the Server unreachable from heartbeat error message very quickly (setHeartbeatTimeoutMs = 3000ms) after disabling WiFi. I’ve debugged this a bit, it’s calling WebSocketAdapterText:close, but takes some time before calling the WebSocketAdapterText.onClose callback (which calls the socket.onDisconnect)
My idea is that the WebSocket.close function is taking a while before completing since it’s doing a closing handshake on the socket (see: WebSocket.close() - Web APIs | MDN).
My suggestion would be to implement another callback on the WebSocketAdapterText, which will be called when the ping/pong failed. This way we can detect “connection problems” very soon. But also keep the onDisconnect callback, since a closed websocket is something else compared to a failed ping/pong.
Another option would be to completely ignore the onClose callback of the actual socket and call the onDisconnect callback when ping/pong is failing, but this might be tricky for some browsers.
Hey @RobinM you’re absolutely right and apologies for not catching the delay between the heartbeat timeout and the onclose event firing in our testing. I am going to have a think on the correct step forward here and update the JS client once I do.
I am sympathetic to the approach of a separate heartbeat callback, but my concern is most developers will either forget to attach to it or, if they do attach to it, call websocket.close() which would bring us to the same issue. It may still be the best approach – but going to have a think.
No worries regarding not catching the delay. I actually have the same concern with the extra callback approach after implementing it today the client library. We’ll test this approach on our side and I’ll let you know if there is indeed a delay.
Will create a PR if it’s working correctly and add you as a reviewer.