A WAL-G physical restore restores the whole PGDATA directory, including pg_authid, so credentials from the backup snapshot overwrote any password rotated after that backup was taken. Credential reapplication was previously only queued when a restore was part of an in-progress clone, so a plain restore to the same project, or an unpause (which shares the same completion path), skipped it entirely and could leave db_user with a stale password. Logical restores are unaffected: pg_dumpall runs with --no-role-passwords, so a logical backup never carries password hashes to begin with.
Supabase now reapplies current credentials after every physical restore completes, regardless of whether it is part of a clone.
A related fix also closes a data-loss path in cloning status tracking: reapplying credentials for a non-clone restore could, on retry exhaustion, flip an unrelated and already-completed clone's status back to failed, which could let a later stray clone request overwrite that project's data. Status transitions are now scoped to clones that are actually in progress.