Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

db schema declarative sync: no way to fail (non-zero exit) when the generated migration is destructive

Abierto Apto para principiantes
  • ¿Algo no está bien?
#7,026 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

  • #7037 de @milekv — cerrado sin fusionar

Evaluación

Dificultad
2/5
Tiempo estimado
1-3 horas
Aptitud para principiantes
84/100
Tipo de issue
Nueva funcionalidad
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
typescript
Área
cli

Línea de trabajo

Comienza en el puntero en apps/cli/src/commands/db/schema/declarative/sync/sync.handler.ts:538-547, donde result.dropWarnings se imprime en stderr; rastrea cómo se declaran los flags para el comando sync y cómo se establecen los códigos de salida en el resto del CLI. Añade un flag --fail-on-destructive (y, si es viable, una salida JSON de las advertencias) para que el comando devuelva un código de salida distinto de cero antes de escribir la migración. Verifica con los pasos de reproducción del issue, comprobando echo "exit=$?" tanto con el flag como sin él, y busca tests existentes alrededor del sync handler.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

✨ Feature supabase/cli

Summary

supabase db schema declarative sync --no-apply prints Found destructive changes in schema diff. Please double check if these are expected: to stderr when the planned migration contains drops. It still writes the migration file and exits 0. CI jobs and scripted workflows cannot tell a destructive plan from a safe one without scraping the human-readable stderr text. --output-format json does not help either: this command prints no JSON.

Feature request: a flag such as --fail-on-destructive, or a distinct non-zero exit code, that makes sync fail when the plan contains destructive changes. Ideally the flag would also skip writing the migration file. Including the drop warnings in --output-format json would also help.

Environment

  • Supabase CLI 2.119.0 (npm package, darwin-arm64), bundled @supabase/pg-delta 1.0.0-alpha.56
  • Postgres 17.11 (public.ecr.aws/supabase/postgres:17.11.0.002)
  • macOS 26 (Darwin 25.3.0, arm64)

Steps to reproduce

  1. supabase init, then add one migration: CREATE TABLE public.d (id int);

  2. Run:

    supabase start
supabase db reset --local
supabase db schema declarative generate --local --overwrite
rm supabase/schemas/public/tables/d.sql
supabase db schema declarative sync --no-apply; echo "exit=$?"

Expected

A supported way to make this run fail on a destructive plan, either through an opt-in flag or a dedicated exit code, so a pipeline can stop before a drop is committed.

Actual

Applying migration 20260101000007_table.sql...
Generated migration SQL:
DROP TABLE "public"."d";

Created new migration at supabase/migrations/20261006190533_declarative_sync.sql
Found destructive changes in schema diff. Please double check if these are expected:
DROP TABLE "public"."d"
exit=0

supabase db schema declarative sync --no-apply --output-format json gives the same plain-text output and also exits 0.

Impact

Sync runs unattended (in CI, a pre-commit check, or an agent loop) and sees exit code 0. A schema file that was deleted or moved by mistake therefore becomes a committed DROP TABLE migration without any gate. The warning already exists. It just cannot be acted on programmatically.

Pointer

In the v2.119.0 tag (c66274cc6dc278a9413a6b0f099367ce150555ac), apps/cli/src/commands/db/schema/declarative/sync/sync.handler.ts:538-547 prints result.dropWarnings to stderr after the migration file is written. Execution then continues to the apply decision, and nothing changes the exit status. result.dropWarnings already has the data a flag would need.

Lenguaje dominante
TypeScript
Estrellas
2.4k
Forks
531
Merge medio
1 d 4 h
PR fusionados (30 d)
351

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de supabase/cli

Todos los issues de supabase/cli

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.