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

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?

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,

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.

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).