Problem

Fixes #2335.

When a user logs out while concurrent in-flight requests are being processed, the middleware was writing a fresh Set-Cookie header to roll the session in every response. If any of those responses arrived at the browser after the logout response the session cookie was silently restored, leaving the user apparently still authenticated.

Root Causes

Two separate issues contribute to the bug:

1. StatefulSessionStore – no existence check before rolling write

StatefulSessionStore.set() called store.set(sessionId, session) unconditionally. If the session had already been deleted by a concurrent logout (via store.delete()) the write would re-insert it, reviving the session.

2. Middleware – rolling update fired even when rolling: false

The else branch in AuthClient.handler() that touches sessions on every non-auth request was reading and re-writing the session even when the session store was configured with rolling: false. This is the TODO that has existed in that branch since the feature was written.

Fixes

Fix 1 – StatefulSessionStore.set(): guard against reviving a deleted session

Before persisting a rolling-session update the store is now queried with the session ID found in the incoming request cookie. If the session no longer exists (a concurrent logout already called store.delete()) the write is skipped and no Set-Cookie header is emitted. The browser never receives a revived session cookie.

The guard only applies to rolling updates (sessions with an existing cookie, isNew = false). Brand-new sessions (fresh login, first visit) bypass the check so those flows remain unaffected.

// src/server/session/stateful-session-store.ts
if (existingSessionId !== null) {
  const existingSession = await this.store.get(existingSessionId);
  if (!existingSession) {
    return; // session was deleted (logout) – do not re-create it
  }
}

Fix 2 – Middleware: honour rolling: false

A new isRolling getter is exposed on AbstractSessionStore. The middleware now gates the session-touch block behind this.sessionStore.isRolling, eliminating unnecessary reads from the session store (and the associated Set-Cookie responses) when rolling sessions are disabled.

// src/server/auth-client.ts
if (this.sessionStore.isRolling) {
  const session = await this.sessionStore.get(req.cookies);
  if (session) {
    await this.sessionStore.set(req.cookies, res.cookies, { ...session });
    addCacheControlHeadersForSession(res);
  }
}

Limitations

The stateless (cookie-only) session store cannot be fixed with a pure server-side guard because all session state lives in the encrypted cookie itself — there is no server-side record to check for revocation. For stateless sessions the recommended mitigation remains to scope the middleware matcher to /auth/* routes only, or to migrate to a stateful session store.

Tests

• stateful-session-store.test.ts – three new cases under rolling session race condition:

  • A session deleted in the store (simulating a concurrent logout) is not re-created.
  • A session that still exists in the store is rolled normally.
  • A new-login session (isNew = true) bypasses the guard (session fixation prevention takes priority).

• auth-client.test.ts – one new case verifying that no Set-Cookie header is emitted when rolling: false.