Supabase CLI migration repair after a failed db push: when is it safe to mark a migration reverted?

Failed migration leaves the database in an intermediate state

When supabase db push fails partway through a migration, the CLI does not roll back automatically. The documented recovery path is supabase migration repair, which marks a migration as applied or reverted in the schema_migrations table without re-running the SQL, or supabase db reset, which destroys local data. Neither option verifies that the recorded state matches the actual database state.

Assume a recent Supabase CLI version and a hosted project on the Pro plan with PITR enabled (7-day retention). The goal is a repeatable team procedure for deciding which recovery mechanism to use after a failed push: repair the migration record, restore via PITR, or rebuild from a branch.

The uncertainty is consistency: if a migration partially executed (some DDL committed, some not), marking it reverted may leave orphaned objects, while marking it applied may skip statements that never ran. PITR restores the whole cluster to a timestamp, not a single migration, and branching environments do not sync schema back to main automatically.

1. What criteria determine whether migration repair is safe versus when PITR or a full reset is the correct recovery path?
2. How should partial DDL execution be audited before choosing a repair status?
3. Is there a documented way to test this recovery flow in CI before it happens in production?