Web: job queue view drops to 'could not verify credentials' after extended watching; other tabs still navigable

[aaronsb]

Summary

Leaving the web UI's job queue open for an extended period eventually causes the jobs list to disappear and a 'could not verify credentials' error to surface in its place. Logging out and back in restores the view.

Observed behavior

• Open the jobs / queue view in the web UI and leave it running (polling).
• After some time, the jobs list vanishes and the panel shows could not verify credentials.
• Other parts of the UI remain navigable, including administrative areas — so the session is not uniformly invalidated from the client's perspective; only the jobs view surfaces the auth failure.
• Workaround: log out, log back in. Jobs view returns to normal.

Why this is interesting

The inconsistency is the bug — either the session is valid (in which case the jobs endpoint should not 401), or it isn't (in which case admin areas should also reject and the UI should force re-auth). Likely candidates:

• Jobs polling uses a token/credential path that expires on a different cadence than the rest of the app (e.g. short-lived job-scoped token vs. session JWT).
• Token refresh isn't wired into the jobs polling loop, so it keeps replaying a stale credential while other tabs refresh on navigation.
• The 401 isn't being handled by the global auth interceptor (no forced logout / re-auth prompt), so the user is left in a half-authenticated state.

Repro

1. Log in to web UI.
2. Navigate to jobs / queue view.
3. Leave it open (exact threshold TBD — minutes-to-hours range).
4. Observe jobs list disappears, replaced by could not verify credentials.
5. Confirm other tabs (e.g. admin) still load.

Acceptance

• Either the jobs view stays authenticated as long as the rest of the app does, or
• A 401 anywhere triggers a consistent re-auth flow across the UI (no half-logged-in state).

[aaronsb]

Root cause hypothesis (from codebase walk)

Polling exposes an expired access token while non-polling tabs don't. There's no token refresh and no 401 response interceptor.

The mismatch

• Access token TTL: 1 hour — api/app/lib/oauth_utils.py:215-222
• Jobs list poll interval: 3 seconds — web/src/components/jobs/JobsWorkspace.tsx:151-157
• Refresh token TTL: 7-30 days, but refresh is never called automatically

Backend (matches the error string verbatim)

• api/app/dependencies/auth.py:226-278 — validate_oauth_access_token() rejects when expires_at < now (line 264)
• api/app/dependencies/auth.py:303 — raises 401 with detail "Could not validate credentials" (this is exactly the string surfaced in the UI)
• api/app/routes/jobs.py:26,72 — jobs endpoints depend on CurrentUser, so every poll re-validates

Frontend (where the gap is)

• web/src/api/client.ts:57-68 — request interceptor attaches the bearer token, but there is no response interceptor, so a 401 never triggers logout or refresh
• web/src/store/authStore.ts:175-211 — refreshToken() exists, just isn't wired to anything
• web/src/components/jobs/JobsWorkspace.tsx:114-118 — fetchJobs() catches the error and renders err.response?.data?.detail directly → that's how "Could not validate credentials" ends up on screen

Why admin tabs still work

Same apiClient instance, different usage pattern. Admin views are click-driven, so after the token expires they simply don't make a request until the user clicks something — and at that point either nothing's been issued yet, or the failure is invisible because the UI doesn't surface it in a banner the way the jobs view does. The jobs view is the canary because it polls every 3s; everywhere else the 401 is latent.

Fix shape (not in scope of this issue, just to frame the work)

1. Add a response interceptor in web/src/api/client.ts that, on 401, calls authStore.refreshToken() once and retries the original request; if refresh fails, force logout.
2. Optionally schedule a proactive refresh ~5min before expires_at so polling loops never see a 401 in the first place.

Either one alone closes the visible bug; (1) is the minimum, (2) is the polish.

[aaronsb]

Maps to endpoint-security audit finding F9 (2026-05-28)

The 2026-05-28 endpoint-security audit (docs/security/endpoint-security-audit-2026-05-28.md, ADR-400) classified this as a high-severity access-control correctness defect, not just a UX bug: the jobs-polling view surfacing a 401 ("could not verify credentials") while other tabs stay navigable means the session is in a half-authenticated state — divergent token lifetimes and no uniform forced re-auth. For internet exposure that's stale-credential replay + inconsistent session invalidation.

The audit recommended folding the fix here rather than filing a duplicate. Suggested acceptance criteria:

• A global 401 interceptor that forces uniform re-auth/logout across all views (not just the jobs poller) when any request returns 401.
• Reconcile token lifetimes so the jobs poller's credential and the session token expire on the same cadence (no view outliving another).
• On forced logout, clear all client-side auth state so no view continues issuing authenticated requests with a dead token.

Context: this was the only finding in the audit that fell outside the endpoint-gating cluster (#431–#441, all merged); it lives on the web/session side, which is why it stays here rather than in that cluster.