Two Logins, One Tab, One Cache Key

A dashboard exposed a brief cross-account display issue because its React Query cache used one constant sessionStorage key for every login within the same browser tab, allowing a newly signed-in user to see a previous user’s cached profile and organizations until fresh network data arrived. The problem became visible after a resilience improvement allowed the application to render available cached data during GitHub outages rather than remain on a loading screen. Instead of attempting to infer sign-outs from unreliable 401 responses, the team scoped cache keys to a value generated or assigned uniquely at login, such as a request-signing session identifier, so each login reads a separate cache entry. This approach does not remove old data or protect against scripts already running on the same origin, and impersonation flows require explicit cache clearing because they intentionally retain a shared server session. Implementing the solution also introduced asynchronous IndexedDB timing risks, storage-eviction edge cases, and failure handling that expanded the initial small change substantially. The account emphasizes testing isolation by deliberately disabling the scoping mechanism and recommends that applications persisting browser caches inspect whether their storage keys are tied to the data owner rather than relying on detecting when cached data becomes stale.

No tracked trend matches for this post yet.

Use this post, company, and trend context to find content marketing opportunities, perform competitive analysis, or address product feature gaps via the Plushcap MCP server or the Plushcap API.