The reading of the full reading's fixes found that every refusal at the address's ceiling moved a reset to 72 hours after it (A1): someone who knows only the address kept the owner's own reset from ever taking effect with one burst every three days, and kept a forgotten one alive (A2). Now a hold-out that begins before a reset takes effect moves it on only by the time it holds the owner out and no hold-out counted before did (account_reset.heldOutUntil, under a row lock), so the owner gets 72 hours outside hold-outs in total; and every reset not carried out lapses 30 days after it was asked (resetLivesAtMost), whatever moved it, besides a week after it took effect. Migration (module, Learn's and Todo's servers, Learn's device schema): ALTER TABLE "account_reset" ADD COLUMN "heldOutUntil" timestamp without time zone; nullable, existing rows counted from now on. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Signed-off-by: Tizian 「ティツィアーン」 <raisondetredev@pm.me>
18 lines
682 B
Text
18 lines
682 B
Text
### AUTOMATICALLY GENERATED DO NOT MODIFY
|
|
###
|
|
### This file is generated by Serverpod when creating a migration, do not modify it
|
|
### manually. If a collision is detected in this file when doing a code merge, resolve
|
|
### the conflict by removing and recreating the conflicting migration.
|
|
|
|
20261019115750898
|
|
20261019200558685
|
|
20261019202835333-deletion-notices
|
|
20261020111123780-passwords
|
|
20261020124836165-sessions-ended
|
|
20261020185619505-recovery-proof-key
|
|
20261020194005842-second-factor-waits
|
|
20261020204618337-session-code-tries
|
|
20261020211224310-email-code-purpose
|
|
20261021100319502-session-ended-warning
|
|
20261021110159448-second-factor-paths
|
|
20261021134802955-reset-hold-outs
|