fix(cutover): make pg17 stageA idempotent (clean v17 db + pg16 guard)#28
Merged
Conversation
stageA created the v17 db only when absent, then pg_restore'd into it. A leftover copy (an earlier stageA, or a hand-staged dump) made the restore fail on duplicate objects — hit live validating the logcheck cutover, where db_logcheck already existed on v17 from a July-2 hand run and had to be dropped manually first. stageA now drops+recreates the v17 db from template0 every run, so it is cleanly re-runnable (and works for the pre-staged logcheck/zyramed dbs). A guard refuses stageA when the project is already bound to pg17, so a re-run can never overwrite a live v17 db with a stale pg16 snapshot — roll back first. Safe because during stageA the app still serves from pg16; WITH (FORCE) just clears any idle leftover connection. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Contexto
Achado ao validar E2E o
cli cutoverno logcheck (1ª execução real do comando — stageA/B/rollback todos verdes). O único gap de código que a validação expôs.Problema
stageAcriava o db no v17 só quando ausente, depois faziapg_restorepor cima. Sedb_<name>já existe no v17 (um stageA anterior, ou um dump pré-staged à mão), o restore bate em objeto duplicado →pg_restoreexit≠0 → stageA falha. No logcheck odb_logcheckjá existia no v17 (Stage A manual de 02/jul) e tive que dropar à mão antes.Morde também: zyramed (tem Stage A manual antigo no v17) e qualquer re-run pós-falha parcial.
Fix
stageApasso 3 agora drop+recreate do db v17 a cada run (fromtemplate0) → idempotente e re-runnable.stageAse o projeto já está empg17(senão sobrescreveria o db vivo do v17 com um snapshot stale do pg16). Rollback primeiro se for re-run intencional.WITH (FORCE)só limpa conexão idle solta.Validação
stageA/stageB/rollbackrodados ao vivo no logcheck viacli cutover(39 tabelas row-parity; GoTrue boot limpo no v17; PostgREST servindo v17; rollback drenou v17 a zero). logcheck deixado no baseline pg16.🤖 Generated with Claude Code