admin
82a8414ffa
ci/woodpecker/push/deploy Pipeline was successful
Real incident: a run had both patroni-0 and patroni-1 stuck forever on "waiting for standby_leader to bootstrap", never even attempting to race for the role. Root cause was leftover etcd/patroni data on disk from a prior interrupted run (operator stopped it short) — the postgresqlha stack itself was gone, but etcd-1/2/3-data still had persisted raft state including a real /service/postgres-ha/initialize key and old replication slot records. Fresh Patroni nodes booting against that non-fresh etcd correctly concluded the cluster already existed and deferred forever waiting for a leader that could never appear, since nobody actually held the lock. rollback.sh's own data-dir wipe only fires when it detects the HA stack IS currently present (Case D/E) — if the stack was already gone by the time cleanup ran, its Case A path never touches the data dirs, leaving exactly this trap. Added a "Pre-Phase-0" check that runs before preflight.sh's ~6+ minute pg_dumpall: detects a still-present postgresqlha stack OR non-empty etcd-*/patroni-*-data left over from a prior run, and — since this is destructive and the operator explicitly wants this to be a deliberate choice, not silent automatic cleanup — prompts interactively before tearing down/wiping. Non-interactive sessions (no tty) hard-fail with a clear message rather than guessing; AUTO_CLEANUP=yes in the environment skips the prompt for deliberate unattended re-runs. Legacy production data is never touched by any of this.