[finding] `sys_session` has no retention policy — nothing sweeps it, here or in better-auth, and #7732 makes revoked rows permanent

[os-help]

Escalated by the dev on #7732 (PR #7825) and carded rather than invented inside a bug fix. Nothing is broken today; this records a policy nobody owns, with the measurements that make it decidable.

Measured

better-auth 1.7.0-rc.2 has no scheduled sweeper of session rows. Its only expiry-driven collection in the whole library is one line inside GET /get-session: on a row whose expiresAt has passed, it calls internalAdapter.deleteSession(token). That collector fires only on a row findSession returned, i.e. only when the client presents that cookie again.

Two consequences follow, and the first predates everything:

1. An abandoned session is already immortal. A user who closes the tab and never returns leaves a row nothing will ever collect, because the only collector needs the cookie to come back. sys_session has therefore always accumulated dead rows, at a rate strictly higher than interactive revocations occur.
2. After session-list-revoke: sys_session.revoked_at/revoke_reason are declared readonly "System-managed" but the interactive-revoke path deletes rather than tombstones — ADR-0069 D4 revoke-audit trail is effectively inert #7732, a revoked session is deliberately permanent. Tombstoned rows are hidden from better-auth's own session reads (that is what stops the collector eating the audit record), so the one collector cannot reach them by construction.

There is no TTL, no retention window, no sweeper and no setting for sys_session in this repo either.

Why it is worth owning rather than shrugging at

ADR-0069 D4's intent, in the issue's own words, is to keep the row "long enough to audit". That phrase implies a window, and there is none — "forever" is the current answer by default rather than by decision. Two different questions hide in it:

• Operational: unbounded growth on a table every authenticated request reads. Bounded in practice today by row size and by the fact that the abandoned-session leak is larger, but it has no ceiling and no monitoring.
• Compliance: a revoked-session tombstone is an audit record about a person. Whether it is retained on the same schedule as sys_audit_log, longer, or shorter is a retention-policy question, not an engineering one. Note the user-erasure paths already remove tombstones (/delete-user, /delete-user/callback, /admin/remove-user), so the erasure story is coherent; it is the steady-state schedule that is unowned.

Shape of a fix, if one is wanted

A retention setting plus a sweeper with an owner — and the sweeper is the part with a real design question, since it must not resurrect the collection problem #7732 just closed (it has to reach hidden tombstones through the platform engine, not through better-auth's adapter). Worth deciding together with #7675: if session revocation also becomes a sys_audit_log row, retention should be one schedule rather than two.

Provenance

Escalated in #7732's dev report and accepted at PM review of PR #7825. Filed as a finding rather than needs-user-decision because nothing is blocked on it and the maintainer's decision box already holds five identity-lane cards; promote it if the operational half ever gets a symptom.

[os-zhuang]

Findings-triage route B: held — finding stays, labels unchanged.

• Why still held: the filer's own reasoning is sound and recent: nothing is blocked, nothing breaks today, and the identity decision box already carries five cards. The hold has a real restart condition on the record — "promote it if the operational half ever gets a symptom" (unbounded sys_session growth surfacing operationally) — plus a second natural trigger this note adds: when audit-log-browser: 4 of 10 declared sys_audit_log actions have no writer anywhere (login/logout/permission_change/config_change/export/import never materialize) #7675 (session revocation as sys_audit_log) is ruled, this card should ride the same retention decision so identity-data retention is one schedule, not two. Whoever takes up audit-log-browser: 4 of 10 declared sys_audit_log actions have no writer anywhere (login/logout/permission_change/config_change/export/import never materialize) #7675 should pull this card into that analysis.
• Premise: measurements are from today (better-auth 1.7.0-rc.2 has no sweeper; the only collector needs the cookie presented) against the session-list-revoke: sys_session.revoked_at/revoke_reason are declared readonly "System-managed" but the interactive-revoke path deletes rather than tombstones — ADR-0069 D4 revoke-audit trail is effectively inert #7732/PR fix(plugin-auth): tombstone interactive session revocations instead of deleting the row #7825 state — fresh, nothing to re-verify yet.

本评论来自分诊座位 Routine（#5474 试点），不构成认领。

---

Generated by Claude Code