🐛 Bug Report: Default express-session MemoryStore Causes Memory Exhaustion and Total Session Loss on Restart

[Ridanshi]

📜 Description

Summary

The backend currently uses the default express-session MemoryStore in production.

MemoryStore is explicitly documented as:

• non-production-ready,
• memory-leaking under real traffic,
• non-persistent,
• and incompatible with horizontal scaling.

As implemented, all authenticated sessions:

• exist only in process memory,
• are lost on restart,
• and accumulate without durable persistence.

---

Affected Files

backend/server.js
backend/package.json
docker-compose.yml

---

Root Cause

express-session is initialized without a configured session store:

app.use(session({
  secret: process.env.SESSION_SECRET,
  resave: false,
  saveUninitialized: false,
}));

Without a store: option, Express falls back to the built-in MemoryStore.

The official express-session documentation explicitly warns:

MemoryStore is not designed for production use. It leaks memory, does not scale past a single process, and is meant only for debugging/development.

---

Failure Scenarios

1. Session Loss on Restart

Any:

• deploy,
• container restart,
• crash,
• OOM kill,
• or process recycle

immediately destroys every authenticated session.

All users are silently logged out.

---

2. Memory Growth Under Real Traffic

Sessions accumulate in the Node.js heap with:

• no persistence,
• no centralized storage,
• and unreliable cleanup behavior.

Under sustained traffic:

• heap usage grows continuously,
• garbage collection pressure increases,
• and the process eventually becomes unstable.

---

3. Horizontal Scaling Failure

With multiple backend replicas:

User logs in → instance A
Next request → routed to instance B
Session missing → user appears logged out

The application becomes incompatible with:

• load balancing,
• autoscaling,
• or multi-instance deployments.

---

Reliability Impact

This creates:

• production instability,
• forced user logout loops,
• deployment fragility,
• memory exhaustion risk,
• and broken multi-instance behavior.

The application cannot scale safely in its current state.

---

Proposed Fix

Replace MemoryStore with a production-grade session backend.

Recommended options:

Option 1 — Mongo-backed Sessions

Use:

connect-mongo

since MongoDB already exists in the stack.

Option 2 — Redis-backed Sessions

Use:

connect-redis

for distributed deployments.

Suggested implementation:

store: MongoStore.create({
  mongoUrl: process.env.MONGO_URI,
  ttl: 14 * 24 * 60 * 60,
})

Additional recommendations:

• enable secure cookie flags,
• add session TTL cleanup,
• document required environment variables.

---

Acceptance Criteria

• MemoryStore removed from production usage
• sessions persist across backend restarts
• sessions support multi-instance deployments
• session TTL cleanup configured
• deployment documentation updated
• regression testing/manual verification added

---

Why This Matters

This is a production-blocking infrastructure flaw.

Without a persistent session store:

• deployments are unreliable,
• scaling is impossible,
• and authenticated user experience becomes unstable under normal operational conditions.

What browsers are you seeing the problem on?

No response

📃 Relevant Screenshots (Links)

No response