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

[os-help]

Blocked-by: #10165

⚠️ The former Restart-when: line has been REMOVED, deliberately. This card is no longer waiting on a condition — as of the maintainer's 2026-08-20 option-A ruling it is waiting on a card, #10165, which gives lifecycle.ttl the onlyWhen row filter this object's policy cannot be written without. Leaving a Restart-when: behind would let the daily executable-criteria scan fire on a card that the unlock scan already owns. Its substance is preserved below and nothing else in this body was touched. Ruling and the four-facet analysis: comment 5355771705.

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.

⚠️ Trigger history, kept because it is the useful part. The original trigger read "closed #7675" and fired without delivering what it stood for — #7675 closed 2026-08-16 and did land login/logout as real sys_audit_log rows, but revocation was deliberately excluded: logoutEventFor returns null for every path except /sign-out (auth-session-audit.ts:157), and that module states the reason — "the revoke families already have their own trail (ADR-0069 D4 tombstones)". There are still two trails, not one. The remaining promote-trigger was an operational symptom on sys_session (table size / read latency / monitoring alarm); it never fired, and the card was promoted on the independent ground that sys_session is the odd one out among the objects declaring a lifecycle policy. Every measurement below still stands.

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.

The dispatchable scope, once #10165 lands

Declare a lifecycle policy for ordinary expired/inactive sys_session rows, using the onlyWhen filter #10165 adds:

ttl: { field: 'expires_at', expireAfter: '1d', onlyWhen: { revoked_at: { $null: true } } }

⛔ Hard fence, unchanged and load-bearing: the revoked-row/tombstone retention window is compliance/audit-trail semantics and is NOT in scope. Every option put to the maintainer excluded it explicitly and the ruling did not settle it.

⚠️ Measured, so it is not re-derivable from the object file: a tombstone is a strict superset of an ordinary row (session-tombstone.ts:281-283 stamps expires_at, revoked_at, revoke_reason and clears nothing), and that write backdates expires_at to now - 1000 — so a ttl keyed on expires_at without the filter reaps tombstones first and hardest, with no test going red. The 1d figure is derivable without fresh policy from sys_device_code, the only other managedBy: 'better-auth' transient object.

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 was blocked on it; promoted 2026-08-17, re-routed to domain:engine 2026-08-20, dispatched and measured the same day, escalated on the measurement, and ruled the same day.

[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

[hotlong]

Triage (findings round): graded — held as finding, reasons re-affirmed rather than deferred by silence.

Why held: nothing is broken today, growth is bounded in practice by the larger pre-existing abandoned-session leak, and the compliance half (retention schedule for tombstones-about-a-person) is a policy question that should not enter the decision inbox while it is this crowded and symptom-free. The filer's own promote-trigger stands: an operational symptom on sys_session (table size, read latency, monitoring alarm) promotes the operational half immediately.

One coordination note recorded now so it is not lost: the #7675 split is being executed this round (parent + per-seat sub-issues). Per this card's own analysis, if session revocation becomes a sys_audit_log row under that program, retention should be one schedule, not two — the retention decision here should therefore be taken after #7675's audit-log shape lands, and the decision card, when it exists, should cite both. Re-grade triggers: (1) operational symptom as above; (2) #7675's audit-log sub-issue merging — at that point this card gets re-read against the landed shape.

---

Generated by Claude Code

[hotlong]

State-machine migration, maintainer-authorized (2026-08-13, live triage session: 「我授权你先迁标签」; semantics on #8449): this card is a graded hold — verdict and restart conditions are in the grading comment(s) above — so finding → pm:on-hold. Verdict, restart conditions, domain unchanged.

---

Generated by Claude Code

[os-zhuang]

Hold discharge (triage seat, daily executable-criteria batch): Restart-when: leg 1 fired — #7675 closed completed 2026-08-16 (5/5 sub-issues; the auth-event writers landed, auth-event-audit.test.ts asserts login rows on origin/main).

Re-graded at the merged ref, and the landed platform shape is stronger than the card assumed: a LifecycleService now exists (lifecycle object property + Reaper, per the plugin-audit changelog) with retention declared on 11 platform objects (sys_activity 14d, sys_audit_log 90d hot→archive, sys_job_run 30d, …) — and sys_session is not among them (verified: packages/platform-objects/src/identity/sys-session.object.ts carries no lifecycle declaration on origin/main). Promoted → pm:queue, type Task: declare a lifecycle policy for sys_session through the existing mechanism, mirroring the 11-object batch.

Premise-first for the dev: re-verify the missing declaration on the ref you branch from. And the #7732 interaction is a real semantics question — revoked-session rows currently double as an audit trace; if reaping them proves contract-relevant, stop and report needs_decision rather than picking a retention number silently.

Size/model suggestion: S–M, opus.

---

Generated by Claude Code

[os-project-manager]

⚠️ PM re-read against the landed shape — the restart-when fired nominally but not substantively, and as written it can now never fire again

PM seat os-project-manager, session session_01Y26DJEHSBhhAQ6wwfsHNza. ⛔ Not claiming, not promoting. Recording a measurement that changes what this card is waiting for.

This card's restart-when reads:

Restart-when: closed #7675 (session revocation as sys_audit_log — retention becomes one schedule, re-read this card against the landed shape)

#7675 is closed — 2026-08-16, completed, 5/5 sub-issues. So I re-read the card against what actually landed, and the parenthetical did not come true.

What landed, measured on main (c07d6e8b9)

login and logout are now real sys_audit_log rows — packages/plugins/plugin-auth/src/auth-session-audit.ts builds them, plugin-audit/src/auth-event-audit.ts accepts them, and the auth_events list view at sys-audit-log.object.ts:71 finally has rows to show. That half of #7675 is genuinely done.

But revocation was deliberately excluded, and the module says so in as many words (auth-session-audit.ts:35-45):

A session row is deleted for many reasons that are not a logout: an admin revoke, /revoke-session on another device, ban, user erasure, and better-auth's own collection of an expired row. Recording those as logout would not be a vague audit record, it would be a wrong one — it names an action the subject did not take. The revoke families already have their own trail (ADR-0069 D4 tombstones, session-tombstone.ts)

Enforced, not merely intended: logoutEventFor opens with if (path !== SIGN_OUT_PATH) return null (:157), and SIGN_OUT_PATH is exactly '/sign-out'. Every one of the five interactive revoke endpoints in INTERACTIVE_REVOKE_REASON (session-tombstone.ts:169) produces a tombstone and no sys_audit_log row.

So there are still two trails, not one, and the retention question this card raises is untouched. sys_session.revoked_at tombstones remain permanent by construction (session-tombstone.ts:114 states the cost plainly: "revoked rows are now retained indefinitely"), and nothing sweeps them. Both original measurements still stand — including the one that predates everything, that an abandoned session is already immortal because better-auth's only collector needs the cookie to come back.

Why this needed saying rather than silently re-parking

The trigger was written as a proxy: "#7675 closes" stood in for "the two trails become one." The proxy fired; the thing it stood for did not. Left alone, the card sits pm:queue-labelled behind a spent trigger that can never fire again — parked forever, and invisibly so, which is the half-state shape this repo patrols for. I have corrected the trigger line in the body to name the substance instead of the proxy; everything else is verbatim.

Disposition — unchanged, and still not mine

Still a finding, still not promotable, for the reason the card gave itself: nothing is blocked, there is no operational symptom, and the compliance half — how long a revoked-session tombstone about a person is retained — is a retention-policy question, not an engineering one. ⛔ That belongs to the maintainer, and I am not adding it to the decision box while the operational half has no symptom. The card's own instruction ("promote it if the operational half ever gets a symptom") is still the right rule.

One thing the re-read makes more tractable if it is ever promoted: because revocation stayed out of sys_audit_log, the sweeper design question the card flagged is unchanged and unsimplified — it must still reach hidden tombstones through the platform engine rather than better-auth's adapter, or it resurrects the collection problem #7732 closed.

---

Generated by Claude Code