fix(auth0-express): keep migrated sessions alive across the absoluteDuration gap

[frederikprijck]

Summary

A migrated express-openid-connect session keeps its original creation time (the legacy iat), and this SDK expires a session at createdAt + absoluteDuration. This SDK defaults absoluteDuration to 3 days, while express-openid-connect defaults it to 7 days. So a legacy session already older than 3 days is transformed successfully, but the write-back emits a Max-Age=0 cookie the browser drops — a silent logout of exactly the sessions the migration feature exists to preserve. It's invisible to a fresh-login runbook, since a new session is always younger than 3 days.

Changes

• Document that a migrated session keeps its original createdAt, and that absoluteDuration (and inactivityDuration) must be set to at least the old deployment's values — in both the zero-downtime guide and the after example.
• Add a regression test pinning both behaviours: default (session cut short) and configured (session kept alive).

Test plan

• npm test — 266 passing (2 new)
• npm run build, eslint — clean

Part of a 3-PR split of the migration review findings (independent, not stacked).

[cschetan77]

1. The stateless store (MigrationStatelessStateStore) has the exact same absoluteDuration problem. Could we add a symmetric regression test in legacy-compatible-stateless-state-store.spec.ts to match the two new tests in the stateful spec.
2. The stores give no runtime signal when a migrated session is about to be silently killed. The misconfiguration is invisible, developers only discover it through user complaints ("why am I being logged out?"). Should we add console.warn inside the migration stores when a transformed session's age already exceeds absoluteDuration, so the problem surfaces immediately in logs rather than silently dropping cookie. The warning just makes it easier to catch if someone follows the migration guide but forgets to set the durations.

[nandan-bhat]

For the stateless store this step does not reproduce as written. A reload only calls getUser/getSession, which are read only and never call set, so the appSession cookie is not dropped and the user stays logged in. The drop only happens on the first write, for example hitting /refresh-token.

For the stateful store there is also no expired Redis TTL. The example Redis set() writes no TTL at all, so the logout actually comes from the appSession cookie being written with Max-Age=0 on the write back.

Can we reword this step per store so it matches the real behaviour?

[nandan-bhat]

This warns on every read. The stateless store has no write back, and reads (getUser/getSession) never call set, so for an aged session this fires on every request until some write finally drops the cookie. The stateful store only warns once. Could we emit it once (per process, or per createdAt) to avoid spamming the logs?

[frederikprijck]

Reworked this in ff780b4. Rather than warn on every read (or track per-session state to dedupe), the warning now fires once at store construction when sessionConfiguration.absoluteDuration is left unset — which is the actual misconfiguration. The store is built once per app startup, so it logs once, needs no bookkeeping, and surfaces the problem before any user is even affected. An app that explicitly set a value is not warned. The per-read behaviour is now unchanged from the modern-cookie path (aged session returned as-is, cookie dropped on next write).