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

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.