Connection resilience: reconnection behavior after network loss

[n-lark]

Connection resilience: reconnection behavior after network loss

User story

As an operator running dashboards on always-on screens, I want a screen that lost the server to recover on its own, so that nobody has to walk the floor after a network blip or a server restart.

Product Requirements

Release headline	📶 Connection resilience
Pillar	Build
Packaging	All — open source npm package, no tier or feature flag
Dependencies	None. Independent of tags and Canvas
Closes	#1344, #2074, #2149, #2068, #2135
Success	A dashboard left through a server outage of any length reconnects unattended, and a proxy session expiry sends you to login rather than hanging
KPI	No new reports of screens needing a manual touch after an outage, across the two releases following
Out of scope	Stale widgets after reconnect (#913, #1251 — solved by tags); chart history after a Node-RED restart (#1362); server-side scaling
Marketing	No standalone blog. A section in the release blog, phrased as capability
Enablement	Release-notes paragraph for support. No new config surface, so no Expert enablement
Feature brief	To be written

Demo points

• After fix: reload dashboard under http node root #2152 and Handle redirection to login page if session has expired when websocket connection is attempted #2078 — proxy session expires, redirects to login instead of hanging.
• After Undesirable reconnection behaviour  #1344 — two browsers, server stopped and restarted after ten minutes, both recover unattended.
• After Expose Dashboard client connection/disconnection state to Node-RED flows #2135 — a flow logging clients connecting and disconnecting.

The problem

A dashboard that loses its server doesn't recover on its own. On a laptop you refresh. On an always-on display someone walks to the screen.

From #1344:

50 displays showing dashboards. Server maintenance takes it offline for ten minutes. All 50 screens attempt a refresh, land on ERR_NAME_NOT_RESOLVED, and each one then needs a manual touch to come back.

The complaint is the blind refresh, not the retry timing — "blindly refreshing the page without the server even being alive".

Three defects in reconnect():

1. No jitter. Every client retries on the same schedule — 2.5s ×4, 5s ×10, 30s ×8 — so 50 screens hit the server in lockstep.
2. It gives up. After MAX_RETRIES (22, ~5 min) forcePageReload() hard-reloads. If the server is still down the screen lands on a browser error page and stays there.
3. parser error also force-reloads. The auth-proxy case. The code comment calls the reload a fallback — "it doesn't seem that we can do much other than force a reload" — but PR Handle redirection to login page if session has expired when websocket connection is attempted #2078 shows the redirect can be detected and followed.

Child tickets

• Undesirable reconnection behaviour  #1344 — retry behaviour. So that a screen left overnight is working in the morning. Jitter, cap the interval rather than the attempt count, no blind reload against a dead server.
• forcePageReload ignores httpNodeRoot #2149 — forcePageReload() ignores httpNodeRoot. So that a dashboard on a custom path reloads to itself, not a 404. PR fix: reload dashboard under http node root #2152 open.
• Hang with Connection Lost message when using authentication proxy and session times out whilst page is inactive #2074 — auth-proxy session expiry. So that an expired session sends you to login instead of five minutes of "Connection Lost". PR Handle redirection to login page if session has expired when websocket connection is attempted #2078 open.
• Service worker prevents auth redirect when dashboard is behind an authentication proxy #2068 — service worker swallows the auth redirect. So that a PWA behind a proxy can reach login. Reported on iPhone, not reproduced on Android. PR fix: let browser handle navigation requests to support auth proxies #2069 hangs on Android PWA; approach still open.
• Expose Dashboard client connection/disconnection state to Node-RED flows #2135 — client connection state in flows. So that a flow can drop per-client state when a screen goes away. The server already holds the map in uiShared.connections; this surfaces it.

Merge order: #2152 → #2078 → #1344 on top. All three edit the same ~20 lines in reconnect() and forcePageReload().

Constraint to preserve: the retry is count-based rather than elapsed-time on purpose. Android suspends the page so timers don't fire, and a count-based scheme retries promptly on wake (noted on #1344).