feat(cli): set up platform baseline before declarative apply#5515
Merged
Conversation
The `db schema declarative sync` declarative shadow was a bare supabase/postgres image with no gotrue/storage/realtime setup, so declarative schemas that depend on Supabase-managed objects (auth.sessions, auth.jwt(), ...) failed to apply with status "stuck". The migrations shadow already runs SetupDatabase, so the two shadows were asymmetric and platform objects could not resolve at apply time. Extract SetupShadowDatabase (platform baseline, no user migrations) and run it on the declarative shadow before applying declarative schemas, in both the sync (getDeclarativeCatalogRef) and generate cache-warm paths. Platform objects now appear identically in both shadows and cancel out of the diff instead of surfacing as spurious changes or stuck applies. Refs CLI-1601 https://claude.ai/code/session_01ACrX8NXcsYLENnCRXAub3S
Coverage Report for CI Build 27196998344Warning No base build found for commit Coverage: 64.285%Details
Uncovered ChangesNo uncovered changes found. Coverage RegressionsRequires a base build to compare against. How to fix this → Coverage Stats
💛 - Coveralls |
Contributor
Supabase CLI previewnpx --yes https://pkg.pr.new/supabase@5515Preview package for commit |
Coly010
approved these changes
Jun 9, 2026
jgoux
pushed a commit
that referenced
this pull request
Jun 9, 2026
…#5521) Refs CLI-1601 — https://linear.app/supabase/issue/CLI-1601/support-auth-dependencies-in-shadow-db-migrations Follow-up to #5515. That PR taught the declarative apply path to provision the Supabase platform baseline (auth/storage/realtime) on the shadow before applying declarative schemas. This fixes a gap it left in the `generate` → `sync`-with-no-migrations handoff. ## The bug `getGenerateBaselineCatalogRef` exports `.temp/pgdelta/catalog-baseline-<version>.json` immediately after creating the shadow — **before** any platform setup runs — so the cached baseline represents a bare postgres image. That same file is reused by `getMigrationsCatalogRef` as the diff **source** when there are zero local migrations. After #5515, the declarative **target** is built on top of the platform baseline. So a no-migration `sync` diffs: - source: bare postgres image - target: platform baseline + declarative schema instead of the intended: - source: platform baseline - target: platform baseline + declarative schema Platform-managed objects (`auth`, `storage`, `realtime`, grants, functions, …) no longer cancel and surface as spurious additions in the generated migration — e.g. a single declarative `public.profiles` table referencing `auth.users` produces a migration that also tries to create the `auth`/`storage`/`realtime` platform objects. ## The fix Provision the platform baseline in `getGenerateBaselineCatalogRef` **before** exporting, so the baseline catalog consistently means "platform baseline, no user migrations" — identical to `diff.MigrateShadowDatabase` with zero migrations, and in parity with the declarative target. The now-redundant second `setupShadowDatabase` call in `Generate`'s cache-warm path is removed since the reused shadow already has the baseline (it was previously provisioning the platform twice). This also fixes a latent `generate` issue: with a bare baseline, `generate` would have emitted platform schemas into the user's declarative files. ## Tests - `TestGetGenerateBaselineCatalogRefSetsUpPlatformBaseline` — pins the setup-before-export ordering. - `TestGenerateThenSyncWithNoMigrationsCancelsPlatformObjects` — full generate → no-migration sync flow through the public command functions, asserting only the user's table is generated and platform objects cancel. Docker/pg-delta seams are stubbed (the established cli-go pattern), so it runs in the standard `go test ./...` CI job. `diff.DiffPgDeltaRef` is now an injectable package var to allow diffing through the public path without the real pg-delta runtime. https://claude.ai/code/session_01ACrX8NXcsYLENnCRXAub3S --- _Generated by [Claude Code](https://claude.ai/code/session_01ACrX8NXcsYLENnCRXAub3S)_ --------- Co-authored-by: Claude <noreply@anthropic.com>
mxcl
pushed a commit
to automic-vault/supabase-cli
that referenced
this pull request
Jun 11, 2026
…e#5515) Refs CLI-1601 — https://linear.app/supabase/issue/CLI-1601/support-auth-dependencies-in-shadow-db-migrations Provision the Supabase platform schema (auth, storage, realtime, etc.) on shadow databases before applying declarative schemas, ensuring Supabase-managed dependencies resolve correctly during both declarative apply and cache warmup. ## Changes - **New `SetupShadowDatabase` function** in `diff.go`: Provisions the platform baseline on a freshly created shadow database without applying user migrations. This allows declarative apply to share the same starting point as migration-based workflows. - **Refactored shadow setup logic**: Extracted common platform baseline setup into `setupShadowConn` helper, used by both `SetupShadowDatabase` and `MigrateShadowDatabase` to avoid duplication. - **Updated declarative apply flow**: - `Generate` now calls `setupShadowDatabase` when reusing the baseline shadow for cache warmup - `getDeclarativeCatalogRef` calls `setupShadowDatabase` before applying declarative schemas - This ensures platform objects (auth.sessions, auth.jwt(), etc.) are available during schema application and cancel out of diffs - **Added tests**: `TestSetupShadowDatabase` validates that the function sets up the platform baseline without applying migrations, and the `Generate` reuse test asserts the baseline is set up before declarative apply. ## Note on baseline caching A persistent "replayable SQL" baseline cache (so services don't boot on cold runs) was considered and intentionally not pursued — the `supabase/postgres` image pre-bakes part of the `auth` schema (overlap on replay), a full `pg_dumpall` replay is fragile (extensions/`shared_preload_libraries`/pgsodium/roles), and a pg-delta-derived baseline currently drops grants. See CLI-1601 for the full rationale. https://claude.ai/code/session_01ACrX8NXcsYLENnCRXAub3S Co-authored-by: Claude <noreply@anthropic.com>
mxcl
pushed a commit
to automic-vault/supabase-cli
that referenced
this pull request
Jun 11, 2026
…supabase#5521) Refs CLI-1601 — https://linear.app/supabase/issue/CLI-1601/support-auth-dependencies-in-shadow-db-migrations Follow-up to supabase#5515. That PR taught the declarative apply path to provision the Supabase platform baseline (auth/storage/realtime) on the shadow before applying declarative schemas. This fixes a gap it left in the `generate` → `sync`-with-no-migrations handoff. ## The bug `getGenerateBaselineCatalogRef` exports `.temp/pgdelta/catalog-baseline-<version>.json` immediately after creating the shadow — **before** any platform setup runs — so the cached baseline represents a bare postgres image. That same file is reused by `getMigrationsCatalogRef` as the diff **source** when there are zero local migrations. After supabase#5515, the declarative **target** is built on top of the platform baseline. So a no-migration `sync` diffs: - source: bare postgres image - target: platform baseline + declarative schema instead of the intended: - source: platform baseline - target: platform baseline + declarative schema Platform-managed objects (`auth`, `storage`, `realtime`, grants, functions, …) no longer cancel and surface as spurious additions in the generated migration — e.g. a single declarative `public.profiles` table referencing `auth.users` produces a migration that also tries to create the `auth`/`storage`/`realtime` platform objects. ## The fix Provision the platform baseline in `getGenerateBaselineCatalogRef` **before** exporting, so the baseline catalog consistently means "platform baseline, no user migrations" — identical to `diff.MigrateShadowDatabase` with zero migrations, and in parity with the declarative target. The now-redundant second `setupShadowDatabase` call in `Generate`'s cache-warm path is removed since the reused shadow already has the baseline (it was previously provisioning the platform twice). This also fixes a latent `generate` issue: with a bare baseline, `generate` would have emitted platform schemas into the user's declarative files. ## Tests - `TestGetGenerateBaselineCatalogRefSetsUpPlatformBaseline` — pins the setup-before-export ordering. - `TestGenerateThenSyncWithNoMigrationsCancelsPlatformObjects` — full generate → no-migration sync flow through the public command functions, asserting only the user's table is generated and platform objects cancel. Docker/pg-delta seams are stubbed (the established cli-go pattern), so it runs in the standard `go test ./...` CI job. `diff.DiffPgDeltaRef` is now an injectable package var to allow diffing through the public path without the real pg-delta runtime. https://claude.ai/code/session_01ACrX8NXcsYLENnCRXAub3S --- _Generated by [Claude Code](https://claude.ai/code/session_01ACrX8NXcsYLENnCRXAub3S)_ --------- Co-authored-by: Claude <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
4 participants
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.
Refs CLI-1601 — https://linear.app/supabase/issue/CLI-1601/support-auth-dependencies-in-shadow-db-migrations
Provision the Supabase platform schema (auth, storage, realtime, etc.) on shadow databases before applying declarative schemas, ensuring Supabase-managed dependencies resolve correctly during both declarative apply and cache warmup.
Changes
New
SetupShadowDatabasefunction indiff.go: Provisions the platform baseline on a freshly created shadow database without applying user migrations. This allows declarative apply to share the same starting point as migration-based workflows.Refactored shadow setup logic: Extracted common platform baseline setup into
setupShadowConnhelper, used by bothSetupShadowDatabaseandMigrateShadowDatabaseto avoid duplication.Updated declarative apply flow:
Generatenow callssetupShadowDatabasewhen reusing the baseline shadow for cache warmupgetDeclarativeCatalogRefcallssetupShadowDatabasebefore applying declarative schemasAdded tests:
TestSetupShadowDatabasevalidates that the function sets up the platform baseline without applying migrations, and theGeneratereuse test asserts the baseline is set up before declarative apply.Note on baseline caching
A persistent "replayable SQL" baseline cache (so services don't boot on cold runs) was considered and intentionally not pursued — the
supabase/postgresimage pre-bakes part of theauthschema (overlap on replay), a fullpg_dumpallreplay is fragile (extensions/shared_preload_libraries/pgsodium/roles), and a pg-delta-derived baseline currently drops grants. See CLI-1601 for the full rationale.https://claude.ai/code/session_01ACrX8NXcsYLENnCRXAub3S