Do not federated-logout an active user for one API 401

Sub-tickets

Activity

• wi-cli-venus created · 6w ago
• wi-cli-venus statusChanged · 6w ago
  Implemented session verification before redirect; validating and preparing DEV deployment.
• wi-cli-venus progress · 6w ago
  Implemented the code fix in isolated worktree /tmp/movilba-191-preserve-zero: a single API 401 now triggers an explicit NextAuth session check and redirects only when that authoritative session is absent. The failing endpoint URL and session verdict are logged. Deployment and live browser verification remain pending.
• wi-cli-venus audit-finding · 6w ago
  Audit found getSession confirmation errors could turn an original resolved 401 into a rejected fetch. Fixed with an inner session-check try/catch that logs and returns the original response; a network failure is not treated as proof of logout.
• wi-cli-venus assigned · 5w ago
  unassigned
• wi-cli-venus assigned · 5w ago
  coder-mba-l-ca
• wi-cli-venus audit-finding · 5w ago
  Gate classification: the deployed global fetch interceptor correctly preserves an active NextAuth session, but apiClient consumes the returned 401 and independently hard-navigates to /user/login. Vehicle detail uses apiClient, so this is a real bypass of the guard rather than a legitimate-user rejection. In isolated worktree /tmp/movilba-201-session-guard, apiClient now verifies NextAuth before navigation; it retains the original 401 if confirmation fails. Targeted ESLint and typecheck pass after linking the existing shared dependencies; Prettier reports pre-existing whole-file style drift.
• wi-cli-venus audit-finding · 5w ago
  Final classification after audit: RootLayoutClient wraps every app route in LayoutContent, so useApiErrorHandler owns every browser apiClient fetch. The DEV implementation from 18711cf3 (v5.4.97, ancestor of current DEV v5.4.200) checks NextAuth before a 401 redirects and preserves the original response when confirmation fails. apiClient's apparent raw-401 redirect runs only after that guarded fetch handler; a duplicate guard was reviewed and deliberately removed because it would double-check/double-navigate. Targeted ESLint/typecheck and isolated production build passed. Audit was source-only; live active-session 401, expired-session, and confirmation-network-failure flows remain unexercised.
• wi-cli-venus completed · 5w ago
  Already delivered on DEV by 18711cf3 / v5.4.97 and confirmed present in current v5.4.200. Audit verified the universal LayoutContent guard protects apiClient vehicle-detail calls; duplicate wrapper change removed. Static lint/typecheck/build passed; documented that no live authenticated-session scenario was available for runtime exercise.
• wi-cli-venus statusChanged · 5w ago
  Reopened: audit identified that reverting restored apiClient's unconditional post-guard 401 redirect. Implementing the single-owner fix: global handler decides redirects; apiClient falls through to ClientError.
• wi-cli-venus verified · 5w ago
  Re-audit approved the single-owner patch. Static vehicle-detail check: its dropdown and primary vehicle apiClient requests are each enclosed in local try/catch, so the expired-session redirect's newly-settled ClientError is handled there. Full production build, typecheck, targeted ESLint, and diff --check pass. Runtime authenticated scenarios remain unavailable.
• wi-cli-venus completed · 5w ago
  Shipped the single-owner 401 policy to DEV in 7eb760a0 / v5.4.203 (current DEV v5.4.204 includes it). A valid NextAuth session preserves the API 401 as ClientError; only the global session-confirming handler redirects expired users. Removed the prior forever-pending promise. Audit approved; static checks/build passed; live authenticated coverage unavailable.
• wi-cli-venus commit · 5w ago
  DEV deployment succeeded: commit 7eb760a0 / v5.4.203. Current DEV/origin advanced to fab02caa / v5.4.204 by a subsequent MOVILBA-247 deploy; 7eb760a0 is confirmed as its ancestor and current dev source has apiClient's 401 fall-through. Re-audit approved. Validation: targeted ESLint, typecheck, full production build, diff --check; static vehicle-detail callers catch the typed error. Runtime active/expired-session scenarios remain unexercised.
• wi-cli-venus verified · 5w ago
  Post-ship coverage check: parsed all non-test src .ts/.tsx files with the TypeScript AST and found 0 direct apiClient method calls without either an enclosing try/catch or a chained .catch. The previously noted expiry-path typed error therefore has lexical handling at all current direct apiClient call sites; no separate follow-up item required. This remains static coverage, not a live auth-session test.
• wi-cli-venus verified · 5w ago
  Scope correction for the post-ship AST check: it examined direct apiClient method calls only—111 sites across 59 files, within 319 non-test src files; 0 lacked a lexical try/catch or chained .catch. This is static direct-call coverage only. It does not prove handling at indirect wrapper boundaries that await/rethrow (for example usePagination, PermissionContext, or usePasswordExpiration), and it does not exercise runtime auth behavior.