A guard reads a session that is still loading and bounces signed-in users to sign-in on reload; why, and what fixes it?

## The symptom and the cause The report is always the same shape: clicking around the app works, but reloading a protected page — or opening a link to one in a new tab — lands the user on sign-in, and a moment later they are signed in after all. Nothing is wrong with the session. What is wrong is that the guard asked a question whose answer had not arrived yet and treated the silence as a "no". Restoring a session is asynchronous work: reading a persisted credential, exchanging it for a fresh one, fetching the account and its permissions. On a cold start that work begins roughly when the app boots and the router's first match happens immediately, so the guard and the restore are in a race the guard usually wins. ## Three states, not a boolean | State | Meaning | Correct guard behaviour | |---|---|---| | **Unknown** | the restore has not finished | wait — decide nothing yet | | **Authenticated** | an identity and its permissions are known | apply the route's requirement | | **Anonymous** | the restore finished and there is no session | redirect to sign-in, carrying the intended target | A boolean has room for only two of these, so the third one has to be encoded somewhere — and the place it is usually encoded is "false", which is exactly the bug. An expired credential is *not* a fourth state: it resolves to anonymous once the attempt to refresh it fails. ## What an asynchronous guard must do 1. **Await a resolution, not a snapshot.** The guard reads a value that is already resolved or a promise-like handle it awaits. It never branches on the raw "unknown" value. 2. **Await one shared restore.** Several guards on a matched chain, plus the app shell, must join the same in-flight work. Each starting its own means duplicate network calls, a slower first screen, and verdicts that can disagree. 3. **Decide only on a resolved value**, then proceed, redirect to sign-in, or redirect to a forbidden screen. 4. **Abandon superseded work.** If the user navigates again while the guard waits, the stale verdict must be dropped rather than applied to the newer navigation. ## Where the pending UI lives On an in-app navigation the router already has a screen on the display, so the honest behaviour is to keep it and show a small pending indicator: the user stays where they were until the verdict arrives. On a cold start there is nothing to keep, so the app needs a deliberate neutral screen — the shell, a skeleton, a logo — for the interval before the first verdict. Two tempting alternatives are both wrong: - **Render the protected screen optimistically** and swap it if the guard rejects. That is the render-then-redirect leak with extra steps. - **Render the sign-in form** while the session is unknown. It is the most common version of this bug, and it is worse than a blank screen, because a user who is actually signed in is shown a login prompt and may type credentials into it. ## Traps around the same bug - **Capturing the wrong intent.** If the redirect fires under the unknown state, the destination recorded for after sign-in may be a route the user was only passing through, or sign-in itself. - **Pushing instead of replacing.** A pushed sign-in entry leaves the guarded URL one step back in history, so Back returns to it, the guard fires again, and the user ping-pongs. - **Loops through the sign-in route's own guard.** If sign-in is guarded by "only for anonymous visitors" and that guard also reads the unknown state, the two guards can redirect to each other. Guards must never redirect while the answer is unknown. - **A per-guard restore.** Duplicated restore calls can also produce a torn view: one guard sees anonymous, the next sees authenticated. - **Waiting forever.** If the restore can hang, the pending screen needs a deadline and a resolved outcome — treat a timed-out restore as anonymous and say so on the sign-in screen, rather than leaving a spinner up. ## The related mistake with permissions The same collapse happens one level in: a route needs a role, the account resolved but its permission set has not, and the guard reads an empty list as "no roles" and shows a forbidden screen to an administrator. Model the permission set with the same three states as the session, and let the guard await it too. ## What interviewers listen for - That you name the unknown state unprompted and refuse to fold it into false. - That you explain why in-app navigation hides the bug entirely. - That your pending design covers the cold start, where there is no previous screen. - That you mention replacing rather than pushing the sign-in entry, and the loop risk between two guards.