Spontaneous Auto-Logout Stale-Closure Guard Automation: A Safety Check That Could Never See a Session

Writing an explicit guard against a specific bad outcome — here, treating an unexpected session-loss signal as suspicious rather than acting on it immediately — is a deliberate, principled engineering decision, and getting it into the code at all reflects the right instinct. That instinct is only as good as the actual, current values the guard reads at the moment it runs. A value captured inside a JavaScript closure that is created once and never re-created reflects the state of the world at the exact moment the closure was created — not the state of the world when the closure is later CALLED, which, for a callback that lives for the life of a long-running page, can be an arbitrarily long time and an arbitrary number of state changes later. A guard reading such a value is not making a slightly-outdated decision; if the value it depends on can only ever be its very first, initial value, the guard is making the SAME decision every single time, regardless of anything that has actually happened since.

Centriu Axis maintains an explicit product principle, stated directly in its own code comments: the application must never sign a user out spontaneously, on its own initiative, without that user's own deliberate action. The reasoning is concrete — an authentication provider can occasionally report a transient, false loss of session (a network blip, a provider-side quirk during token refresh), and reacting to that report by immediately clearing the user's session and forcing a fresh login is a worse outcome for a real person mid-task than simply tolerating a request that might briefly return a 401 until the session self-corrects.

A specific guard exists to enforce exactly this: whenever an authentication state-change handler receives an event reporting no current session, before clearing any application state, it checks a boolean — had this user genuinely been authenticated a moment ago? — and, if so, refuses to proceed with the logout, deliberately leaving the user on-screen with their last known session rather than treating a sudden, unexplained signal as authoritative truth.

That check, before this fix, computed its answer as `!!supabaseUser || !!session` — reading both `supabaseUser` and `session` directly as React component state, from inside a function (`processSession`) defined ONE TIME, inside a `useEffect` whose own dependency array is `[loadProfile]`, itself a `useCallback` with an empty dependency array — meaning `processSession` itself is created exactly once, when the component first mounts, and is never recreated for the rest of that component's life. A function defined once in JavaScript closes over the specific variable BINDINGS that existed at the moment it was created — not over whatever those variables' values happen to be later. Both `session` and `supabaseUser` are `null` at the exact moment a fresh page first mounts (a session has not yet had the chance to load). The guard's read of `!!supabaseUser || !!session`, therefore, permanently evaluates against those two ORIGINAL, first-render values, for the entire remaining life of the page — regardless of how many times the user's real session state actually changed afterward, and regardless of how long they had genuinely been logged in by the time any later event fired.

The practical consequence: the guard built specifically to say "this user had a session a moment ago, do not clear it on an unexplained signal" could never once see that the user had one — its own two inputs were permanently fixed at `null` and `null`. Any unexpected null-session event, at any point after the very first render, would find `hadAuthBefore` evaluating to `false`, and the guard would let the logout proceed — precisely the spontaneous, self-initiated sign-out the entire mechanism exists to prevent, passing through it every time it mattered. A closely related check a few lines later, deduplicating a specific `INITIAL_SESSION` event by comparing an incoming user ID against `supabaseUser?.id`, suffered the identical defect for the identical reason, always comparing against the same permanently-null original value.

The fix introduces two refs, `sessionRef` and `supabaseUserRef`, initialized from the corresponding state and explicitly reassigned to the current state value on every single render (`sessionRef.current = session`, immediately after the `useState` hooks, executed unconditionally each render pass) — a ref's `.current` property, unlike a variable captured by a closure, is read fresh every time it is accessed, regardless of when the surrounding function was originally defined. The guard now computes `hadAuthBefore` from `!!supabaseUserRef.current || !!sessionRef.current`, and the `INITIAL_SESSION` deduplication check now compares against `supabaseUserRef.current?.id` — both reading the genuinely current session state at the exact moment the check actually runs, rather than the state that existed when the enclosing function was first created. The refs are additionally updated synchronously, inline, at the exact point `processSession` itself calls `setSession`/`setSupabaseUser` — ensuring the very next invocation of the guard, even one firing in the same tick, already sees the update, rather than waiting for React's own state-update-and-re-render cycle to complete first.

Before the fix, a person genuinely logged into Centriu Axis for an extended session, experiencing a single transient authentication hiccup — a token refresh briefly failing against a flaky network — would trigger the guard meant specifically to protect against exactly this scenario. That guard's own check for "did this user have a session a moment ago?" would evaluate against two values still fixed at their original, page-load values of null and null, answer "no," and let the spontaneous logout proceed — clearing a genuinely active session over a transient blip, the precise outcome the guard existed to prevent. After the fix, the same guard reads the user's actual, current session state via a live ref, correctly recognizes a genuine prior session, and keeps the user signed in through the transient event.

Centriu Axis's guard against spontaneous, self-initiated logout now reads a user's genuinely current authentication state at the moment it checks, rather than a value permanently frozen at the component's first render — closing a gap where the guard's own core check could never actually detect that a user had a prior session, meaning the specific event it exists to catch could pass through unblocked in every real-world case after the very first render.

This automation governs Centriu Axis's own internal defense against spontaneous, unexplained session termination — it does not change how a user's own deliberate sign-out works, and it does not add a new authentication feature; it corrects an existing guard's ability to actually see the condition it was already designed to check for.

Reading component state directly inside a callback is the more natural, common pattern in React, and works correctly whenever the callback itself is recreated on every render (which most are, by default). The specific risk is a callback deliberately defined only ONCE, inside a one-time-effect pattern chosen for a genuinely good reason (avoiding a duplicate initial load on mount) — that same one-time definition permanently fixes whatever state values the callback references at their first-render values. Mirroring the specific values a stale callback needs into refs, updated on every render regardless of the callback's own lifecycle, preserves the original one-time-setup benefit while giving that callback a way to see genuinely current data whenever it actually runs.