fix(db): torna migrations pendentes idempotentes p/ destravar integração prod#335
Conversation
…ção prod A integração main->prod (Supabase protected branch) aplicava as migrations pendentes em ordem e falhava em 20260524210002 com SQLSTATE 42710 — a policy "Anyone can request a password reset (validated)" já existia em prod (criada out-of-band). Mesmo padrão em 20260524210300 (3 policies kill_switches admin) e 20260525063000 (CREATE OR REPLACE VIEW não pode mudar count(*) de bigint p/ integer). Correções idempotência-only (validadas contra o estado real de prod): - 210002: DROP POLICY IF EXISTS do nome validado antes do CREATE. - 210300: DROP POLICY IF EXISTS antes de cada CREATE POLICY (insert/update/delete admin). - 063000: DROP VIEW IF EXISTS + CREATE VIEW (em vez de OR REPLACE) p/ permitir troca de tipo das colunas de contagem; nada depende das views (verificado em pg_depend). Os outros 7 pendentes já eram idempotentes (IF NOT EXISTS / IF EXISTS / REVOKE / CREATE OR REPLACE sem conflito de assinatura). 0 migrations órfãs. https://claude.ai/code/session_01MBTzmQYmrgwLnwfxRS3PNU
|
This pull request has been ignored for the connected project Preview Branches by Supabase. |
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
Caution Review failedThe pull request is closed. ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (3)
WalkthroughTrês migrations SQL consolidam padrões de idempotência em políticas RLS, adicionam índice de performance em kill_switches, e recriam views observability com drop explícito antes da criação para evitar conflitos em re-execução. ChangesDatabase Migrations: RLS Hardening and View Redeploy
🎯 Effort Estimate🎯 2 (Simple) | ⏱️ ~8 minutes As três migrations são padrões diretos de SQL: adds de políticas com DROP IF EXISTS (idempotência), criação de índice single-column, e redeploy de views com padrão drop-create. Baixa densidade lógica, sem lógica condicional complexa ou dependências entre migrations. Review é verificação de syntax SQL, correção de nomes de policies/índices e impacto em RLS. Suggested Labels
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
There was a problem hiding this comment.
Pull request overview
Este PR ajusta três migrations Supabase pendentes para serem idempotentes (replay-safe), evitando falhas na integração main → prod quando objetos (policies/views) já existem em produção por terem sido criados out-of-band.
Changes:
20260524210002: adicionaDROP POLICY IF EXISTSda policy"Anyone can request a password reset (validated)"antes doCREATE POLICY.20260524210300: adicionaDROP POLICY IF EXISTSpara as policies admin (insert/update/delete) emsystem_kill_switchesantes de recriá-las.20260525063000: trocaCREATE OR REPLACE VIEWporDROP VIEW IF EXISTS+CREATE VIEWpara permitir mudança de tipo nas colunas agregadas (ex.:count(*)).
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
| supabase/migrations/20260524210002_harden_password_reset_requests_rls.sql | Torna a recriação da policy de password reset idempotente ao dropar também o nome “(validated)” antes do CREATE. |
| supabase/migrations/20260524210300_kill_switches_fk_index_and_policy_consolidation.sql | Evita colisões ao recriar policies admin existentes em prod, adicionando DROP IF EXISTS por policy. |
| supabase/migrations/20260525063000_restore_smoke_test_observability_contract.sql | Evita erro de alteração de tipo em views existentes usando DROP+CREATE mantendo GRANT/REVOKE/COMMENT após recriação. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Contexto
Após o PR #334 reparar as 4 migrations órfãs, a integração
main→prod (Supabaseprotected branch) passou a aplicar as migrations pendentes em ordem — e falhou
na primeira não-idempotente,
20260524210002, com:A causa raiz: vários objetos foram criados out-of-band (MCP/dashboard pela sessão
paralela), então os
CREATE POLICY/CREATE VIEWdessas migrations colidem ao seremre-aplicados pela integração.
Diagnóstico (validado contra o estado real de prod)
Das 10 migrations pendentes, só 3 eram não-idempotentes. As outras 7 já usavam
IF NOT EXISTS/IF EXISTS/REVOKE(no-op) /CREATE OR REPLACEsem conflito deassinatura. 0 migrations órfãs (confirmado: o erro "Remote migration versions not
found" sumiu).
20260524210002CREATE POLICY "...(validated)"já existe em prodDROP POLICY IF EXISTSdo nome validado antes do CREATE20260524210300kill_switches_{insert,update,delete}_adminjá existemDROP POLICY IF EXISTSantes de cada CREATE20260525063000CREATE OR REPLACE VIEWnão troca tipo das colunascount(*)(bigint→integer)DROP VIEW IF EXISTS+CREATE VIEW(nada depende delas — checado empg_depend)Validações feitas
pg_policy: confirmado que as policies depassword_reset_requestsesystem_kill_switchesjá existiam em prod.pg_proc/information_schema:fn_run_schema_drift_check(210400) e as funçõesde smoke-test ainda não existem em prod →
CREATE OR REPLACEcria limpo, semconflito de tipo de retorno.
pg_depend: nada depende dev_smoke_tests_latest_run/v_smoke_tests_trend, entãoo DROP+CREATE é seguro.
223000: as 5 tabelas e seus parents/funções já existem →IF NOT EXISTStornatudo no-op.
Observação (overlap com sessão paralela)
As views de smoke-test em prod apontam para
smoke_tests_runs(plural), enquanto063000cria/usasmoke_test_runs(singular) — esse é o contrato pretendido pelamigration da sessão paralela. Após aplicada, as views passam a ler a tabela singular
(inicialmente vazia, repopulada por
fn_run_and_persist_smoke_tests). O histórico natabela plural fica preservado, apenas órfão. Não renomeei — é decisão de design da
sessão paralela; apenas garanti que aplica sem erro.
Test plan
main→prod aplica as 10 pendentes sem erro 42710 (branch-actionlog verde)schema_migrationspassa a conter as 10 versões pendenteshttps://claude.ai/code/session_01MBTzmQYmrgwLnwfxRS3PNU
Generated by Claude Code
Summary by cubic
Torna três migrations pendentes idempotentes para destravar a integração main→prod no Supabase. As demais pendentes já eram idempotentes; não restam migrations órfãs.
Written for commit ef5fec4. Summary will update on new commits. Review in cubic
Summary by CodeRabbit