LiveView falls back to Longpolling too often

[PJUllrich]

Environment

Elixir: 1.15.7
Erlang: 26.1.2
Phoenix: 1.7.11
LiveView: 0.20.5
Bandit: 1.2.0
macOS: Sonoma 14.3

Actual behavior

Ever since I upgraded to Phoenix 1.7.11 and enabled longpolling by default, LiveView falls back to longpolling 60-90% of the time instead of opening a WebSocket. I experienced this with my production servers running on Fly, but also in Localhost. I updated the longPollFallbackMs option from the recommended 2500 to 5000, 10_000, and even 15_000, but could observe no change in behaviour. Previously, I had no issues with establishing a WebSocket connection in any of my environments and if I disable longpolling by removing the longPollFallbackMs option, it establishes a WebSocket connection without issues.

I also experienced an issue with Bandit, which might be related. Please see the error and my configuration here: mtrudel/bandit#299

Expected behavior

I expect LiveView to fall back to longpolling almost never, especially not in Localhost.

[chrismccord]

It sounds like what is happening is in development a new request triggers the phoenix CodeReloader plug which compiles project changes, and those changes take longer than 2.5s, which triggers the longpolll fallback. Note that longpoll fallback is memoized in sessionStorage on the client for the remainder of the browser session, so that is my guess on why increasing it to seemingly very high numbers had no effect - it was already memoized to fallback. One option could be to check the window.pathname for localhost and conditionally fallback so you don't fallback in dev, but I don't think this is something we need to change internally. Sounds like everything is working as intended. You can verify by clearing your session storage or restarting the browser and seeing that it does not fallback with the high values. Thanks!

[mtrudel]

@PJUllrich for the sake of completeness, can you verify that this also happens on Cowboy, all else being equal?

[PJUllrich]

@mtrudel ha, that's interesting. I mentioned that I saw longpolling on localhost which surprised me. I switched out Bandit for Cowboy 2.10.0 and the issue was gone! I enabled Bandit 1.2.1 again, and it fell back to longpolling again. Once more, I switched to Cowboy and saw longpolling probably because the phx:longpolling flag in sessionStorage was set to true. I deleted that flag, refreshed and had a WebSocket connection again. Curious.

[mtrudel]

@PJUllrich so does it relate to the server being run or not?

[PJUllrich]

I'm sorry I don't fully understand your question. But if you mean whether the issue is related to Bandit vs Cowboy, my suspicion would be yes, it might

[mtrudel]

That's what I was getting at; thanks!

I can't see where this would be the case but I'll look at it this morning!

[mtrudel]

Just spun up a new 1.7.11 test app and everything seems to work as expected on Bandit. A couple of things to try and diagnose:

• What browser are you using?
• Does anything come up in either the client or server logs regarding the websocket failure that precipitates the fallback? Maybe something in the browser inspector?
• To Chris' hunch, do you notice if it correlates with any actions you take, such as code reloading?

[chrismccord]

Are you using Brave by chance?

[PJUllrich]

Not on my laptop right now but I experience the issue in the latest Arc on macOS and latest Safari in iOS. Know sure whether it helps but I experience this issue on a multitude of LiveView routes both locally and in production (Fly)

Maybe unrelated, but another issue I experience is that the websocket connection never completes on the connected load. So, the static page renders and then the mount/3 and handle_params/3 callback execute for a second time but the browser never receives that update, so never fully establishes a websocket connection. The loading bar just keeps on loading until the timeout is reached and the website refreshes. I think that's why I experience so many longpoll fallbacks.

I saw some errors when I connected my iPhone to my laptop and opened the iOS Safari console there. I can send you a screenshot in a few hours. In Arc, I didn't see any logs unfortunately.

[PJUllrich]

I also disabled any ad blockers. Same issue. Since I switched back to Cowboy, all seems to work fine but I haven't tested it thoroughly yet.

[mtrudel]

Maybe unrelated, but another issue I experience is that the websocket connection never completes on the connected load. So, the static page renders and then the mount/3 and handle_params/3 callback execute for a second time but the browser never receives that update, so never fully establishes a websocket connection. The loading bar just keeps on loading until the timeout is reached and the website refreshes. I think that's why I experience so many longpoll fallbacks.

If it's possible, I'd love to see a screenshot of the websocket request in your web inspector's Network tab. It's possible this is more related to how Bandit's websock implementation calls in to Phoenix's Socket layer, rather than a protocol level websocket issue.

[PJUllrich]

@mtrudel I'm sorry to have wasted your time on this, but I tried to replicate this issue today and I just don't see it anymore which is weird. I tried it on Safari and Arc on macOS and Safari on iOS but nothing shows up. I've seen some errors in Safari on macOS when I navigated from a LiveView to a Controller route and back, but I don't think it's related. I did a forced recompile of my project maybe that resolved it? It's weird because I've seen WebSocket time outs also in production, so that rules it out, but I just don't see the issue anymore.

I'll keep an eye on this and will ping you here if I see the websocket timeout issues again, but I think we can move on for now.

These were the errors that I've seen on Safari 17.3 on macOS Sonoma 14.3, but I think that's Safari related and not Bandit related.

Navigating from a LiveView route to a Controller route

Navigating from a Controller route to a LiveView route

The errors for the websocket ending with vsn=2.0.0 are related to the live-reloading, so no issue with Bandit or LiveView. I also see these errors with Cowboy. There's only one error related to the "real" websocket in the first picture when I navigate away from a LiveView with a <.link navigate={~p"/pricing"}> link. But I doubt that that's causing the issue that I've reported.

Again, sorry for wasting your time on this. I'll ping you if I see it again.

[mtrudel]

Good(ish?) to hear. If it does come up again, the most useful thing to see would be the relevant network views from your inspector.

[walter]

Thanks for your work on Longpoll fallback and Bandit.

I'm back-enabling Longpoll fallback for an existing app and I'm seeing something similar in dev with Chrome and Safari (cycling failures to connect when longPollFallbackMs is declared). I mention this not to get issue re-opened as I'm guessing it very specific to my app, but as a data point.

I also switched from Cowboy to Bandit. I haven't switched back to see if that fixes things yet.

It's the end of my work week, so won't be able to give details until my Monday, but will try to follow up then.