- Shipped
- August 22, 2026 at 9:03 PM UTC
- Author
- kamo
- Commit
- 83c2790
A load of / showed a burst of 401/403 before the session settled — user-info, ui-preferences, by-department, chat/unread, timezone/effective and tickets/pending-count all failing together, then everything working. It reads like a first-paint race on the home page. It is not one, and the session is not late: two /api/user-info calls 22ms apart carried a 128-char token and no token at all respectively. They are two different pages. /validate and /logout have no layout of their own, so the root layout mounts the whole authenticated provider stack over them — against a session that by construction does not exist yet on the page whose job is to create it, and has just been destroyed on the other. Every one of the seven "no session ID" bursts in a pod's log window lands within seconds of an OTK validation or a logout, and none anywhere else. The 403 on tickets/pending-count is the same cause, not a missing right: MediaService answers a session-less request 403 where SecurityService answers 401. The noise was the visible half. A login splash was also opening a STOMP connection, subscribing to presence, arming the sound catalogue and the notification deck, and polling counts — to be torn down a second later by window.location.href. So the stack moves into AuthedChrome, which renders the page bare on a pre-session path. Both are a fixed, full-viewport LoadingScreen, so neither wanted the nav-offset content box either. SessionBootstrap is hoisted ABOVE the gate: /validate writes the token whose reader it installs, so it has to be mounted on the one page the shell is not. Deep-link capture, the loading manager and the themed favicon were already above it and stay there. The path list was three copies before this — a private EXEMPT_PATHS in each god mode component and an inline check in useUserInfo's 401 handler, which special-cases the same two paths so an expected 401 does not bounce a visitor to /logout from /logout. One authority now, so a third pre-session page cannot be added to two of the three. Exact match, not prefix: proxy.ts deliberately treats /validate/* as public, and the client gate should not widen on its own. Also here, both found while tracing the same console: - sessions/support/auto-open 404'd because the proxy hop was never written. MediaService has served it all along; only the Next route was missing, and AutoOpenUnreadSupportChats swallows a non-ok answer by design, so support conversations assigned while an agent was away silently never opened. - /favicon.ico 404'd twice per load. The real favicon is themed and injected at runtime; nothing answered the browser's default probe. Added to public/ and NOT app/, deliberately: an app/favicon.ico makes Next emit a <link rel=icon> ahead of DynamicMetaLoader's themed links, and TabAttention mutates the FIRST icon link it finds — it would badge the wrong one and the badge would vanish. In public/ it is served without a tag, and TabAttention's own /favicon.ico fallback now resolves instead of failing to load. Verified: npx tsc --noEmit, npm test (2706 tests, 187 files), npm run build.