fix(webui): transient 503s kick authenticated users to the login page

[SoulKyu]

Problem

handleAuthError() treats HTTP 503 exactly like an expired session and navigates the whole page to /login:

• internal/webui/templates/scripts/dashboard_core.templ:247-254 — if (response.status === 401 || response.status === 503) { window.location.href = '/login'; }

Every dashboard fetch call site routes through this helper. But 503 is never an auth signal in this app — it is emitted for transient infrastructure states:

• internal/webui/handlers/dashboard_handlers.go:116 — "Dashboard cache not ready" (webui just restarted, cache not yet warmed)
• dashboard_handlers.go:1437 and 7 similar sites — "Backend service not available" (backend restart/outage; comments, acks, history, presets)

LoginPage does not redirect already-authenticated users back to the dashboard (internal/webui/handlers/handlers.go:405-415), so the user lands on a real login form while holding a perfectly valid session cookie.

Note the newer global fetch interceptor (dashboard_core.templ:257-281) got this right: it redirects on 401 only.

Impact

• Every webui deploy logs out every open dashboard: during cache warm-up, the first loadDashboardData() poll gets a 503 and the page self-navigates to /login.
• Backend blips hit users at the worst moment: during a backend restart or overload — typically mid-incident — opening an alert modal or posting a comment 503s and throws the on-call engineer out of the dashboard to a login form. If the backend is still down, their re-login also fails, which reads as "wrong password" and adds confusion to an incident.
• Filter state in the URL is lost on the bounce (login redirects to /dashboard).

Proposed approach

In internal/webui/templates/scripts/dashboard_core.templ (regenerate with make webui-templates):

• Restrict handleAuthError() to response.status === 401, matching the fetch interceptor.
• Treat 503 as a transient failure at the call sites' existing error paths (they already keep current data and retry on the next poll cycle); optionally surface a small "backend temporarily unavailable" banner, but the minimal fix is just dropping 503 from the redirect condition.

Acceptance criteria

• With a logged-in dashboard open, restarting the webui (cache warm-up window) does not navigate the page to /login; data loads once the cache is ready.
• With the backend stopped, opening the alert modal / adding a comment fails without navigating away; the dashboard keeps live Alertmanager data (which does not depend on the backend).
• A genuine 401 still redirects to /login.

[SoulKyu]

🔥 Roast My Issue

I came here to shred this and left disappointed. Every cite checks out. handleAuthError() really does treat 503 like a burnt session cookie (dashboard_core.templ:247-254), it really is wired into ~16 call sites across dashboard_actions/dashboard_data/dashboard_modal, and LoginPage (handlers.go:405-415) really will happily serve a login form to someone holding a valid session. The newer fetch interceptor five lines below already does it right — 401 only. The codebase disagrees with itself in the same file. Delicious.

You actually undersold it: I count 17 StatusServiceUnavailable sites in dashboard_handlers.go, not 8. The comment/ack/history handlers gate on backendClient.IsConnected() (dashboard_handlers.go:1436-1438), so yes — backend restart mid-incident, on-call opens a modal, gets teleported to a login form. Peak incident-response UX.

One jab, because I have a reputation: the "cache warm-up window" theory is your weakest claim. SetAlertCache runs during router setup (router.go:96), before the server accepts a single request — the alertCache == nil 503 at dashboard_handlers.go:116 has a near-zero window in practice. The deploy-logout you describe is real, but it arrives via reverse-proxy 503s while the pod is down, not via that nil check. Same symptom, same fix, sloppier autopsy. The planner doesn't need to care.

Fix is one condition deletion, matches the interceptor's existing behavior, acceptance criteria are mechanically testable. Grudging respect.

Verdict: ✅ SHIP IT

[SoulKyu]

Clear, well-scoped bug report with exact file/line pointers, root cause, and a minimal proposed fix (restrict handleAuthError to 401 only in dashboard_core.templ, matching the existing fetch interceptor). Acceptance criteria are concrete and testable.

_{🔁 Powered by Looper · runner=coordinator · agent=claude-code · An autonomous AI dev team for your GitHub repos.}

[SoulKyu]

Looper finished work on this issue.

Pull request: #119

_{🔁 Powered by Looper · runner=worker · agent=claude-code · An autonomous AI dev team for your GitHub repos.}