fix(session): reduce session maxAge from 365 to 90 days - #1365
Open
itsalaidbacklife wants to merge 1 commit into
Open
fix(session): reduce session maxAge from 365 to 90 days#1365itsalaidbacklife wants to merge 1 commit into
itsalaidbacklife wants to merge 1 commit into
Conversation
The production Redis session store (Mini plan, 25MB) was hitting maxmemory and rejecting all writes with "OOM command not allowed", which silently broke login (sessions never persisted). connect-redis derives each session key's Redis TTL from the cookie's maxAge, so the 365-day maxAge meant session keys lived ~1 year and accumulated until the store filled. Reducing maxAge to 90 days lets memory turn over naturally. Paired with an allkeys-lru eviction policy on the add-on. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
itsalaidbacklife
added
version-patch
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
Production users could log in (the flow appeared to succeed and landed them on HomeView), but their sessions were never persisted — the game-list request errored and a refresh booted them back to login.
Server logs showed the root cause was the Redis session store, not the app:
The production Redis add-on (Heroku Mini plan, 25 MB,
maxmemory-policy: noeviction) had filled up. Undernoeviction, Redis rejects every write once full — so authenticated sessions were never written, and the login response had already been sent (hence the accompanyingCannot write to response more than once/response headers have already been sentwarnings).Why it filled up
connect-redis@6.1.3derives each session key's Redis TTL from the cookie'sexpires/maxAge(_getTTLinlib/connect-redis.js). Withcookie.maxAgeset to 365 days, every session key lived ~1 year and accumulated on a 25 MB store until it wedged.Change
Reduce
cookie.maxAgefrom 365 → 90 days inconfig/session.js. Because connect-redis couples the Redis key TTL tomaxAge, new session keys now expire in ~90 days (refreshed on activity viatouch), so memory turns over naturally. Active users are unaffected; only genuinely idle sessions expire.Operational fixes already applied out-of-band
FLUSHALL) to restore login immediately.allkeys-lruas a safety net so a full store evicts LRU sessions instead of rejecting all writes.This PR is the durable code-side complement to those.
Follow-ups (not in this PR)
secretinconfig/session.jsto an env var (pre-existing; out of scope for this outage fix).🤖 Generated with Claude Code