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
691 B
Text
18 lines
691 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.
|
|
|
|
20261019193547604
|
|
20261019201213254-profiles
|
|
20261019204122341-deletion-notices
|
|
20261020111950710-passwords
|
|
20261020125124942-sessions-ended
|
|
20261020185752014-recovery-proof-key
|
|
20261020194229631-second-factor-waits
|
|
20261020204619863-session-code-tries
|
|
20261020211225101-email-code-purpose
|
|
20261021100422779-session-ended-warning
|
|
20261021110200318-second-factor-paths
|
|
20261021134804476-reset-hold-outs
|