handling-authentication-errors

Detect AppTokenValidationError in API catch blocks by checking err.name, err.data?.name, err.error?.name, and err.body?.name, then throw a custom AuthTokenExpiredError. At the UI level, show a Session Expired modal with a Refresh page button that calls window.location.reload().

Probe GET /api/account/me with credentials included and classify responses: 401 means anon, 403 with known business codes means blocked, and anything else means unknown. Retry unknown verdicts with delays of 0, 400, and 1200 ms before showing a transient server error, never clearing the session cookie.

A deploy restarts the app backend, so requests during rollout can hit 502s or timeouts from the proxy while the pod is not ready. Code that treats any non-401 failure as logout falsely ends valid sessions; retry the session probe and show a retryable server-unavailable message instead.

No. For public apps, anonymous visitors receive a 401 from /users/me, which means not authenticated rather than session expired. Return null from the fetch and reserve AuthTokenExpiredError for Dashboard or data API 401s carrying AppTokenValidationError.

The platform proxy may answer expired sessions with a 302 redirect, which fetch follows into a cross-origin CORS failure with no status or body. Use redirect: 'manual', detect opaqueredirect responses, then probe the session before deciding whether to show an auth modal.

Status 0 is almost never an auth problem; it means the request went to the wrong platform host and died on network or CORS. Fix host resolution using same-origin relative paths, window.location.hostname, or /fusebase-env.json rather than build-time environment constants.