Frontend fails to recover from brief connection drops on unstable mobile/roaming networks

[hedlung]

Describe the enhancement

When connecting via the mobile app or a browser over an unstable mobile network (e.g. international roaming with full signal strength but high latency/packet loss), the frontend’s websocket connection setup fails almost instantly and repeatedly, rather than degrading gracefully or retrying the specific failed request. Since signal strength (bars) does not reflect actual link quality, and the initial state sync is done as a single long-lived websocket session, any brief interruption forces a full restart of the connection and state fetch. Suggested improvements: retry the websocket handshake with backoff instead of failing outright on the first drop; fetch initial state incrementally/in smaller chunks rather than one large sync, so a partial success can be resumed rather than restarted; distinguish more clearly in the UI between “server unreachable” and “connection unstable, retrying.”

Use cases

This affects anyone accessing Home Assistant remotely over a mobile connection that is unstable rather than simply slow — for example international roaming, rural coverage, or a moving vehicle. Right now the app becomes effectively unusable in exactly the situations where checking on your home remotely matters most, even though the server itself is healthy and reachable.

Visual examples

No response

Anything else?

Reproduced consistently: connected via Nabu Casa remote access on a mobile network with full signal bars but poor underlying connection quality. Login completed successfully, but the frontend immediately failed to establish its websocket connection and pull state — even a lightweight page like /config/info, with no dashboard cards or history data, showed the same “Unable to connect. Retrying in X seconds” behavior once past login. Confirmed via direct terminal access to the Home Assistant host during the failures that this was not server-side: Supervisor, all containers, and networking were fully healthy (ha resolution info returned no issues, docker ps showed all containers Up, ha network info showed working internet). The behavior was observed via the iOS Companion app specifically, but the underlying issue is in the shared frontend/websocket logic. Switching the phone from 5G to 4G did not help, and the failure got faster rather than slower, which points away from a bandwidth/timeout issue and toward the websocket handshake itself being dropped and not retried.

Related discussions I found: frontend#17454, frontend#11038, frontend#17409, iOS#3879 — similar symptoms around websocket reconnection robustness, though none exactly matches the instant-fail-on-drop behavior described here.