I am seeing the following errors in a mobile and a desktop browser after the devices wake up from short sleep when accessing the LiveView (vsn 1.0.5) server:
Uncaught (in promise) Error: A listener indicated an asynchronous response by returning true, but the message channel closed before a response was receivedUnderstand this errorAI
app-2b0afc197cdceeb5c92611615d031f1a.js?vsn=d:28 WebSocket connection to 'wss://********.com/live/websocket?_csrf_token=MRIhNjQqCyQAACBjFSgxDi8XFXsOBDU9rwDdEAnVgvp1_lBaXyG8ZsFb&_track_static%5B0%5D=https%3A%2F%2F********.com%2Fassets%2Fapp-e7baf904e1e50202d94c8a4610601ef5.css%3Fvsn%3Dd&_track_static%5B1%5D=https%3A%2F%2F********.com%2Fassets%2Fapp-2b0afc197cdceeb5c92611615d031f1a.js%3Fvsn%3Dd&_mounts=2&_mount_attempts=0&_live_referer=https%3A%2F%2F********.com%2Fapp%2Forg%2Fuhost&vsn=2.0.0' failed:
Any suggestions how to make sure that the LiveView WebSocket clients properly reconnect after waking up from sleep without needing to reload a page?
I don’t think there is something you can do to fix this.
A websocket connection requires constant ping/pongs for it to not be closed by network equipment, if the connection idles for a certain amount of time, a router will no longer allow traffic on that port. If the device/browser doesn’t respond to server pings, because the device is in battery saving mode, then the connection will inevitably close. The only option would be to somehow force the device to not stop the browser activity even in sleep mode.
There is also LongPoll, as an alternative to websockets for phoenix liveview, but it will most likely suffer from the same fate.
My question is not so much about keeping that connection, which is obviously impossible, but about why wouldn’t a client be able to reconnect? After all it’s an https request to the same port that is open to public, that gets upgraded to a websocket. Based on the observed behavior there is no reconnect attempt, which seems wrong to me. Is this a bug in LiveView?
This is a problem that plagues some of us and has been talked about 'round here before. There have been just a few reports of this happening consistently on Fly’s hobby tier. I had an app on this was used by just myself and a friend. The odd thing is that he would encounter it on mobile and I would encounter it on desktop. I have another project on AWS that has more users (by which I mean, like, maybe 10) and I’ve had one report of this happening one time. So ya, it may be a provider issue, possibly location issue? I’m really not sure. It’s super annoying when it happens, though.
I have this ticket, but never got around to doing a simple reproduction.
The way we work around it is do a window.reload when app comes back into focus
But this was in the context of a native app and using webview