This adds three new scheduled cleanup jobs that clear the last_active_ip
field from sessions that have been inactive for more than 30 days:
- CleanupInactiveOAuth2SessionIpsJob
- CleanupInactiveCompatSessionIpsJob
- CleanupInactiveUserSessionIpsJob
This helps with data minimization by not retaining IP addresses longer
Implements hard deletion of user/browser sessions that have been finished for more than 30 days, but only after all child sessions are cleaned up.
User sessions can only be deleted when no child sessions exist, ensuring backchannel logout propagation continues to work correctly.
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.
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.
This rewrites the database migration code to:
- avoid deadlocks when running multiple migration processes at the same
time with a `CREATE INDEX CONCURRENTLY` statement
- allow us to remove some migrations from the code base and mark them as
intentionally removed
- allow us to modify some migrations and declare alternate checksums
for previous versions of the migration
Introduces some admin API endpoints for Personal Sessions.
- add: Creates a personal session along with its first personal access token, returning both. This is currently the only way to get a personal access token.
- get: Shows the information about a personal session
- list: Shows many personal sessions
- revoke: Revokes a personal session, so it can't be used anymore
- regenerate: Revoke the active personal access token for a session and issue a new one to replace it.
Unify the admin API, CLI, and GraphQL API in not having the unlock
command also reactivate, or the deactivate command also lock.
Still let the unlock command of the CLI and GraphQL API to also
reactivate the target user, albeit as a non-default option.
- Allow the admin API to deactivate a user without locking it, and to
unlock a user without reactivating it.
- Make unlock-and-reactivate flows unset the "deactivated_at" timestamp.
- Revert adding an "unlock" parameter on `ReactivateUserJob`, as the
option is used only by the admin API which doesn't use a job.
