I'm trying to work through error handling with your web messenger SDK when a customer's internet connection is flaky (which can easily happen for customers on mobile devices).
If I start a conversation with an agent and then switch my machine into airplane mode, after a handful of seconds, the SDK fires the MessagingService.reconnecting event and your widget displays a "Reconnecting" banner. I expected MessagingService.offline to fire but it does not. Under what circumstances is offline supposed to fire?
Then if I reconnect to the internet, your widget stays stuck with the "Reconnecting" banner and never indicates to the user that it has reconnected. The user however can still send a message and if the user does, it seems then that your widget only then figures out it reconnected and removes the banner. That seems like a bit of a bug. But I also expected the MessagingService.reconnected event to fire and it never does. Under what circumstances is that supposed to fire?
The docs also list a conversationDisconnected event but I never see that fire either and I'm not sure if I should expect it to or not.
Are you seeing this behavior consistently or inconsistently? We depend on the following browser events to determine offline vs online. In airplane mode, I'm wondering if you are still connected to any Wifi with internet access? In that case, there won't be any offline event published.
MessagingService.offline event is published as soon as browser publishes above offline event. When device is back online, browser publishes online event and we then publish MessagingService.online event. Now that we know connection is back, we try reconnecting publishing MessagingService.reconnecting event. Otherwise, if you are still offline, you should see Connection lost banner in the Messenger UI staying there until that offline duration.
MessagingService.reconnecting event indicates that we are trying to open the WebSocket connection. It looks like for you at this stage, it is stuck forever, meaning the attempt to opening Web Socket connection is still not resolved and thats why it still did not publish MessagingService.reconnected event. Ideally, this isn't the case and you should see this "Reconnecting.." banner go away itself indicating that it reconnected followed by a loading indicator to restore any messages itself.
I would suggest to please check you are not connected to any Wifi and that browser is publishing its native events as Messenger expects.
The conversationDisconnected event is unrelated to this. Its related to a Conversation Disconnect feature in Messenger allowing to disconnect conversation from Agent side and thats when this event is published.
Yeah, I am seeing the behavior consistently with both Chrome and FF. I also tried pulling the incoming network cable from my router and I get the same result. I was about to come here and suggest that you are probably relying on navigator.onLine. Unfortunately, that property is not reliable when the value is true. If you are still connected to a local network but have lost internet access, onLine will still be true. It seems to also still be true even if your machine is put into airplane mode or the wi-fi turned entirely off.
The only way I see onLine switching to false is if I explicitly "Work Offline" in Firefox (Chrome does not have a similar mode). If I use the FF offline mode, I do see the offline and reconnected events get fired as expected. And of course, if you still have internet access but the Genesys servers are down or unreachable, this onLine flag won't catch that either.
I haven't tested on an actual mobile device which is where this would matter most. I don't know what happens if you lose a cell signal. But I suspect the result is that you guys are not getting the disconnect/reconnect behavior you want.
I was indeed testing in mobile switching off mobile data and these offline/online events were triggering as expected and like wise in desktop. But I do agree that it may not be always reliable due to the limitation around native Javascript API (navigator.onLine).
Obviously, the only other alternative would be for us to keep making actual network requests to determine network status but that could be a performance hit, that said I think combining these two techniques we may be able to determine more accurately. This is something we will evaluate more and look into it, thanks for pointing it out.