An end-to-end suite loads its authenticated session from a state file committed to the repository. It passed for weeks, then every test started failing with a redirect to the login page. What went wrong, and how should that session be produced instead?

## Reading the symptom "Every test suddenly redirects to login" is a distinctive failure. Total, simultaneous, and unrelated to any code change is the signature of a *credential* problem rather than a code problem. The three usual causes, in order of likelihood: 1. The saved session expired. 2. The session was invalidated — the test account's password was rotated, the account was disabled, or a "sign out everywhere" action revoked it. 3. The environment changed under the file — the state was captured against a different origin, or the environment was reset and the account no longer exists. All three point at the same root design error: the session was treated as a static fixture when it is a perishable credential. ## Why a committed state file is doomed Authentication artefacts carry lifetimes by design. A session cookie has a max-age; an access token has an expiry; a refresh token is often single-use and rotated on redemption. Whatever the mechanism, the server decides when the snapshot stops being honoured, and that decision is invisible from the file. The file looks identical on the day it works and the day it stops. There is a second, worse problem: a state file is a working credential for a real account. In version control it is a leaked secret — visible in history even after deletion, and usable by anyone who can read the repo against whatever environment it was minted for. `.gitignore` the directory, and if such a file has already been committed, rotate the account's credentials rather than only deleting the file. ## Produce the session as part of the run The robust pattern is that nothing authenticated is stored between runs: 1. A setup phase runs before the tests, once per identity. 2. It authenticates against the *target* environment, using credentials from the environment (a CI secret), never from a checked-in file. 3. It writes the resulting state to a gitignored working directory. 4. Tests restore from that directory. The freshness question disappears, because the maximum age of any session is the length of one run. Make the setup step fail loudly: ```ts const res = await context.request.post(`${baseURL}/api/login`, { data: creds }); if (!res.ok()) { throw new Error(`auth setup failed for ${creds.email}: ${res.status()}`); } ``` This is disproportionately valuable. Without it, a broken credential presents as every test failing on its first assertion with a message about a missing dashboard heading, and someone spends an hour reading test code. With it, the run stops in seconds with the actual cause. ## Long runs and mid-suite expiry Regenerating per run solves staleness *between* runs. A large suite can still outlive a short-lived access token inside a single run — an access token measured in minutes against a forty-minute suite means tests that start late begin failing while early ones passed. Symptoms: failures clustered at the end of the run, or in the workers that started last. Options, roughly in order: - **Rely on the app's own refresh.** If the app refreshes silently using a longer-lived refresh cookie, make sure the saved state includes it — capturing only the short-lived access token strips the very thing that would have kept the session alive. This is the best answer because it exercises production behaviour. - **Re-authenticate per worker at worker start**, so each worker's session is only as old as its own slice of the run. - **Extend the token lifetime in the test environment.** Effective and cheap, but it means the suite no longer runs under production-like expiry, so an expiry bug can hide. A related gotcha: significant clock skew between the CI runner and the auth server makes freshly-issued sessions look already-expired. If sessions fail immediately rather than after a while, suspect the clock before the code. ## Expiry as a feature worth testing One inversion is worth mentioning: everything above treats expiry as an obstacle, but "what the app does when the session expires" is real product behaviour — a re-authentication prompt, a redirect that preserves the current page, an unsaved-work warning. That deserves its own test, driven by deliberately invalidating or fast-forwarding the session rather than by waiting. Saying so signals that you understand expiry as a behaviour and not just a nuisance.