ops: schedule session reaping — tower-sessions DeletionTask is never spawned, so sessions grow unbounded #159

New issue

Closed

opened 2026-08-09 18:22:44 +00:00 by rosa · 0 comments

rosa commented

2026-08-09 18:22:44 +00:00

Owner

Found during an operational-resilience review (Release It! stability rules).

Location: crates/infra/src/session_store.rs:129 (delete_expired impl); no caller in crates/server/src/main.rs
Severity: High — unbounded growth (Steady State)

Problem

The session store implements tower-sessions' expired-deletion hook, but the accompanying DeletionTask is never spawned at startup. Nothing ever calls the reaper, so expired session rows are never removed. The sessions table grows without bound for the life of the deployment; on the "small box, runs for years" target this steadily inflates DB size, query cost, and WAL pressure until the whole app degrades — with no dependency having failed.

This is the classic Steady-State violation: a mechanism that accumulates a resource (session rows) has no matching mechanism that reclaims it.

Suggested fix

Spawn tower-sessions' continuous deletion task at startup (e.g. session_store.continuously_delete_expired(period)) as a supervised background task, and drain it on graceful shutdown alongside the server and worker monitor.

Found during an operational-resilience review (Release It! stability rules). **Location:** `crates/infra/src/session_store.rs:129` (`delete_expired` impl); no caller in `crates/server/src/main.rs` **Severity:** High — unbounded growth (Steady State) ## Problem The session store implements `tower-sessions`' expired-deletion hook, but the accompanying `DeletionTask` is **never spawned** at startup. Nothing ever calls the reaper, so expired session rows are never removed. The `sessions` table grows without bound for the life of the deployment; on the "small box, runs for years" target this steadily inflates DB size, query cost, and WAL pressure until the whole app degrades — with no dependency having failed. This is the classic Steady-State violation: a mechanism that accumulates a resource (session rows) has no matching mechanism that reclaims it. ## Suggested fix Spawn `tower-sessions`' continuous deletion task at startup (e.g. `session_store.continuously_delete_expired(period)`) as a supervised background task, and drain it on graceful shutdown alongside the server and worker monitor.

rosa referenced this issue

2026-08-09 18:23:01 +00:00

ops: sweep expired confirmations, authorization codes, and invites #160

rosa added the

labels

2026-08-09 18:23:14 +00:00

rosa referenced this issue from a commit

2026-08-10 01:41:28 +00:00