Websocket gets disconnected: Uncaught (in promise) Error

saleyn

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?

9 comments

/phoenix #liveview

0 989 9

2025-03-26 03:24:04 UTC

Showing Posts 1 to 9

Show Best Posts
Show All (oldest first)
Show All (newest first)

D4no0

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.

Post #1

saleyn

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?

Post #2

D4no0

My bad, for some reason I thought that the issue is the disconnection only.

Can you post the full error stacktrace? Also, are there any useful logs or errors on server too?

Post #3

saleyn

What I pasted is all that appears in the js console. The application log doesn’t have anything usefull.

Post #4

D4no0

It seems that this is unexpected behavior, maybe opening a ticket on github might be helpful?

Post #5

sodapopcan

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.

Post #6

D4no0

Seems to me like a bug in JS that doesn’t trigger correctly the reconnection.

Post #7

Neophen

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

https://github.com/phoenixframework/phoenix_live_view/issues/3041

Post #8