Change compat_sessions.user_session_id FK from ON DELETE SET NULL to ON DELETE NO ACTION. This prevents deletion of user_sessions while compat_sessions still reference them, which is critical for backchannel logout propagation.
When an upstream IdP sends a backchannel logout, MAS must trace through:
upstream_oauth_authorization_sessions -> user_sessions -> compat_sessions
If user_session_id links are SET NULL, logout propagation fails.
Uses two-step migration (DROP+ADD NOT VALID, then VALIDATE) to minimize table locking during deployment.
This includes sessions that were never completed, and sessions where
user_session was cleaned up. This is to avoid breaking features like
OIDC Backchannel Logout after 30 days.
flow
The main goal of this is to allow tracking user sessions authed by an
upstream authorization session, but this also has the nice side effect
of allowing 'going back' in browser history within the registration flow
Add scheduled cleanup job that removes old completed and failed queue
jobs after 30 days. Jobs are kept for debugging purposes.
Includes migration to change the next_attempt_id FK constraint from NO
ACTION to SET NULL, allowing cleanup of retry chains without breaking
foreign key constraints.
One caveat is that cleanup is based on their creation time, *not* when
they got completed/failed. This means that if the job takes a long time
(as in, several days) to get scheduled, it might get cleared as soon as
it runs. This is fine for now, we may want to revisit this if we start
scheduling jobs far in the future
Add two cleanup jobs scheduled hourly:
1. Upstream OAuth authorization sessions - removes sessions after 30 days
2. Orphaned upstream OAuth links - removes links after 7 days where user_id IS NULL. These are links created during upstream OAuth 2.0 login but never associated with a user
Add scheduled cleanup job that removes old user recovery sessions after
7 days. Runs hourly.
Implementation uses ULID cursor-based pagination with no additional
indexes needed. Child tickets cascade-delete automatically.
We check if the access token was used when a double-refresh happened,
but can't do that reliably as we started garbage-collecting expired
access tokens
"cleanup-expired-tokens" was not accurate, and since the plan is to have
different jobs for the different kind of tokens, we renamed this job to
use a more accurate description
