Fix immediate fallback to long poll when websocket connection is lost

[peymor19]

When a browser client loses its web socket connection to the server, I noticed that it immediately falls back to long poll without respecting the longPollFallbackMs delay.

This causes all connected browser clients to fall back to long poll when restarting an Elixir server, instead of attempting to reconnect to a new web socket as expected.

I have added a failing test and a potential fix.

I am not sure that the implementation of the fix is the best so I would appreciate some insight on the issue before diving deeper into a better solution.

In this image you can see that I set the longPollFallbackMs to 5500 ms

This image shows the client immediately falling back to long poll instead of waiting the 5500ms for a web socket connection.

Thanks for your consideration!

[matheus1lva]

Im seing exactly the same thing, in my case even some next requests are being aborted because of that!

[lcmen]

I’m learning Phoenix, and I keep running into the same issue during development. When I leave a LiveView tab and then shut down the server, it sometimes falls back to long polling, assigns a fallback long-poll record in the session, and never goes back to WebSockets until I remove the session entry. Is this the expected behavior? Once LiveView falls back to long polling, does it never return to WebSockets?

[SteffenDE]

I'm don't think the expected behavior is to actually wait (AND RETRY) for the given amount. When the WebSocket connection explicitly fails, we try LongPoll immediately. We cannot know why the WebSocket connection failed, it might be a firewall blocking websockets and you wouldn't want to delay all connections unnecessarily. So currently, we only fall back when the websocket connection is stuck.

If you don't want to fallback in development, do something like this:

longPollFallbackMs: location.host.startsWith("localhost") ? null : 2500,

[SteffenDE]

Once LiveView falls back to long polling, does it never return to WebSockets?

@lcmen if WebSockets did work previously, Phoenix will retry WebSockets when you reload the page. Otherwise, Phoenix will retry as soon as the browser session storage is cleared, which usually happens when the last tab for your origin is closed. So if you visit the page later, WebSockets will be tried first again.

[lcmen]

Once LiveView falls back to long polling, does it never return to WebSockets?

@lcmen if WebSockets did work previously, Phoenix will retry WebSockets when you reload the page. Otherwise, Phoenix will retry as soon as the browser session storage is cleared, which usually happens when the last tab for your origin is closed. So if you visit the page later, WebSockets will be tried first again.

Gotcha, thank you for clarificatio @SteffenDE ! I wasn't aware that the goal was to actually keep using longpoll until user closes the browser (and session gets wiped out).

[westmark]

@SteffenDE This happens a bit too often in my setup and I'd be interested in knowing if there is a "clean" way to force Liveview to retry WebSockets? Apart from programmatically deleting the item in SessionStorage and reloading the page, that is. If not I'd be happy to try to add such a feature.

[SteffenDE]

@westmark the following should work

liveSocket.replaceTransport(WebSocket);

How do you decide when to execute that though?

[westmark]

@SteffenDE I was thinking at first to just display a message somewhere with an "Upgrade connection" button. My users are few and technical, so it should do fine. Later on I might try to upgrade on some reasonable interval. However, I guess I will run into trouble with users on company networks with strict WS policies, so maybe I'll have to take that into account as well.