Dashboard Displays Wrong Company Data After Company Switch

Objective

• Fix a session/auth state desync that causes the dashboard to display data from a previously active company after switching instances.
• Prevent users from ever seeing data that doesn't belong to their current company context — even transiently — to protect operational trust and data integrity.

Background

• Users with access to multiple company instances can switch between them via the company switcher in the navbar.
• Under certain conditions — most reliably triggered by logging in while the browser is mid-switch, or switching companies in rapid succession — the active company identity in the session becomes desynchronized from the data being fetched and rendered on the dashboard.
• The result: the URL and navbar may reflect Company A while the dashboard renders data from Company B.
• Clearing cookies does not resolve the issue. The state resets only when the user navigates to a third company and then back to the intended one, suggesting stale company context is held somewhere that a simple cookie clear doesn't flush.
• Confirmed reproducible by both Ryan and Chris on logout/login. Chris noted he had seen this previously and assumed it was isolated.

Product Decisions

Locked

1. Correct behavior — Company context must be fully resolved and data re-fetched before the dashboard renders after any company switch or login event.

Open

1. Stale context location — Is the stale company identity held in a client-side store, a cached server session, or both? The workaround behavior suggests a client-side layer (globalContext, Zustand/React context, or cookie) is not fully flushed on switch. Needs investigation to confirm.
2. Dashboard data fetch timing — Does the dashboard data fetch fire before the new session token is fully applied? If so, a loading/pending gate may be needed to prevent rendering while company context is still resolving.
3. Switch-during-login race condition — Chris noted this is more likely to occur when a login and a company switch happen concurrently. Should the company switcher be gated or debounced during active login/session establishment?

Scope

Frontend

• src/actions/switchCompany.ts — Primary entry point for the company switch action; the most likely location where session state is updated or where a flush/reset should be triggered.
• src/app/tools/globalContext.tsx and src/app/admin/globalContext.tsx — Global context providers; if company identity is held here, these need to ensure stale state is cleared before re-render on switch.
• src/app/tools/notifications/switch-membership/page.tsx — Handles the membership switch notification flow; relevant if switch triggers a redirect that races with session resolution.
• src/components/navbar/NavUser.tsx — Navbar company switcher UI; relevant if the switch action is initiated here.

Backend

• src/util/functions/betterAuth/auth.ts — Core auth configuration; relevant for understanding how company/session context is scoped per request.
• src/util/functions/betterAuth/shared/sessionHelpers.ts — Session helper utilities; likely involved in resolving or updating the active company on the session.
• src/util/functions/betterAuth/web/webAuthEndpoints.ts — Web auth endpoints; relevant if the company switch posts to or relies on an auth endpoint to re-establish context.
• src/routes/session.ts and src/routes/authenticate.ts — Session and authentication route handlers; relevant for understanding the full login + company resolution flow.

References

• Reported via Google Chat by Ryan Wagner and Chris, June 23, 2026.
• Workaround: switch to any third company instance, then switch back to the intended one.