From 4e9ac5346919975bbc3458281e8bd949b3d2e35f Mon Sep 17 00:00:00 2001 From: github-docs-bot Date: Tue, 29 Sep 2026 11:45:39 +0000 Subject: [PATCH] Sync from supabase/troubleshooting --- ...cies-from-embedded-transactions-13ae82.mdx | 21 +++++++++++++++++++ 1 file changed, 21 insertions(+) create mode 100644 apps/docs/content/troubleshooting/partial-migrations-and-schema-inconsistencies-from-embedded-transactions-13ae82.mdx diff --git a/apps/docs/content/troubleshooting/partial-migrations-and-schema-inconsistencies-from-embedded-transactions-13ae82.mdx b/apps/docs/content/troubleshooting/partial-migrations-and-schema-inconsistencies-from-embedded-transactions-13ae82.mdx new file mode 100644 index 00000000000..40a14243491 --- /dev/null +++ b/apps/docs/content/troubleshooting/partial-migrations-and-schema-inconsistencies-from-embedded-transactions-13ae82.mdx @@ -0,0 +1,21 @@ +--- +title: 'Partial migrations and schema inconsistencies from embedded transactions' +topics: + - 'Troubleshooting' + - 'Database' +--- + +If a failed migration leaves partial schema changes or table data in your database without recording the version in `supabase_migrations.schema_migrations`, this is usually caused by explicit transaction control commands inside the migration file. + +### Why this happens + +When migration files include explicit `BEGIN` and `COMMIT` statements, they break the migration runner's built-in transaction wrapper. Any statements executed prior to an embedded `COMMIT` persist durably in your database, even if subsequent statements fail. + +### How to resolve and prevent partial migrations + +1. **Remove explicit transaction commands**: Remove `BEGIN`, `COMMIT`, or other transaction-control statements from your migration SQL files so the migration runner can handle atomicity automatically. +2. **Clean up partial objects**: If a migration containing an embedded `COMMIT` has failed midway, inspect the database and manually roll back or drop any partially created objects before running the migration again. +3. **Verify migration history**: Check the recorded migration history against your actual schema by querying `supabase_migrations.schema_migrations` or running: + ```bash + supabase migration list + ```