Conversation
The docs-spec generator publishes apps/cli/docs into the supabase/supabase CLI reference, and the db pull inputs still described the pre-pg-delta flow. The example responses printed the retired "auth and storage schemas are excluded" line and the migra-era "Setting up initial schema" / "Creating custom roles" progress lines; replace them with the current shadow-database output and the in-sync message the command prints today, and point the custom-schemas example at public,extensions since auth and storage no longer need an explicit pull. In the pull.md overlay, name split plan files with the _1/_2 suffixes the CLI writer actually produces instead of the older unit-name scheme, note the transaction=false directive on non-transactional units, and add a paragraph on which customizations in Supabase-managed schemas the pg-delta engine captures (user triggers, auth policies, storage and realtime policy surfaces). Mirrors supabase/supabase#50220 so the next spec publish keeps that text. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0191XKFXEZ8kHsMNWHAaKgE2
Contributor
There was a problem hiding this comment.
🤖 AI Review
Both independent reviews completed. Four unique findings remain after merging the shared pg_dump finding: three are confirmed and one is refuted. The PR inaccurately attributes managed-schema changes to pg_dump and omits the non-initial --schema limitation; it also leaves pre-existing stale start/reset examples. The alleged missing legacy filename documentation is not a current production issue.
Findings
| Severity | Location | Category | Sources | Claim |
|---|---|---|---|---|
| 🟡 MINOR | apps/cli/docs/supabase/db/pull.md:23 |
documentation-accuracy |
claude+codex | The paragraph incorrectly says the initial pg_dump baseline includes managed-schema trigger and RLS changes; those changes are instead appended by the subsequent migra pass. |
| 🟡 MINOR | apps/cli/docs/supabase/db/pull.md:23 |
documentation-accuracy |
claude | The statement that pg-delta automatically captures managed-schema customizations is overbroad for non-initial pulls using --schema, which exclude actions outside the selected schemas. |
| ⚪ NIT | apps/cli/docs/templates/examples.yaml:42 |
documentation-accuracy |
claude | The edited examples file still contains stale start/reset output strings: Creating custom roles supabase/roles.sql... and Seeding data supabase/seed.sql.... |
Findings outside the diff
- ⚪ NIT
apps/cli/docs/templates/examples.yaml:42— The edited examples file still contains stale start/reset output strings:Creating custom roles supabase/roles.sql...andSeeding data supabase/seed.sql....
Refuted findings (kept for transparency, not posted as review comments)
apps/cli/docs/supabase/db/pull.md:15(documentation-completeness): The split-plan documentation should also describe the writer's suffix-less fallback filenames such as_schema_changes.
Refuted: apps/cli/src/command-internal/pgdelta-engine-runtime.layer.ts:18-19 establishes the next engine as the only production implementation. Its result type requires a string-or-null suffix, and pgdelta-engine.next.layer.ts:88-94 always propagates it. Multi-unit renderer tests verify_1and_2; the cited pull test bypasses that implementation with an old suffix-less mock. The docs accurately describe current production output.
Stats
Claude findings: 4 · Codex findings: 1 · Confirmed: 3 · Refuted: 1 · Uncertain: 0
Models: claude-opus-5 + gpt-5.6-sol · Trigger: auto · Workflow run
This review runs once per PR. A maintainer can request another with a /ai-review comment.
The migra initial pull seeds the migration with a pg_dump that excludes the managed schemas (buildSchemaDumpEnv applies INTERNAL_SCHEMAS when no --schema is passed) and then appends the migra diff to the same file; it is that second pass, not the dump, that carries trigger and RLS policy changes in auth and storage. Say so instead of attributing them to the baseline. Also note that --schema restricts later pg-delta pulls to the listed schemas while the initial pull ignores it. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0191XKFXEZ8kHsMNWHAaKgE2
avallete
enabled auto-merge
September 14, 2026 11:14
avallete
added a commit
to supabase/supabase
that referenced
this pull request
Sep 17, 2026
…#50332) ## I have read the [CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/CONTRIBUTING.md) file. YES ## What kind of change does this PR introduce? Docs update. Stacked on [#49280](#49280). Two commits: 1. Fixes for the four CodeRabbit findings from #49280's latest review round (each verified against the head before changing). 2. Restores the pg-delta opt-in framing after a plan change. ## What is the current behavior? **Plan change.** [#50220](#50220) rewrote the pages to describe `pg-delta` as the default for every project, matching [supabase/cli#6391](supabase/cli#6391). That breaking default flip will not ship before Select, so the CLI keeps its current behavior: a project uses `pg-delta` only when `config.toml` sets `[experimental.pgdelta] enabled = true`, which `supabase init` writes for new projects. Existing projects stay on `migra` until they add it. The branch currently says the opposite in the shared engine partial (embedded in seven pages), the Diff engines page, the workflow and declarative guides, the branching page, the config reference (`default: 'true'`), the `db diff` and `db pull` spec descriptions and flag defaults, and the declarative AI prompt. **CodeRabbit findings.** - The branching troubleshooting page says migrations generated on `pg-delta` "don't need manual reordering". The engine orders statements within one generated migration, not across migrations generated separately on branches that later merge. - The working-with-branches page says `supabase db diff` "never uses your schema files as its baseline" without qualifying the engine; on `migra`, `db diff` does read `supabase/schemas/`. - The declarative walkthroughs run `sync` (which prompts to apply) and then apply manually with `supabase migration up`. - Three pages and the `db pull` spec describe the declarative directory as always `supabase/schemas`, though `experimental.pgdelta.declarative_schema_path` changes it. ## What is the new behavior? **Opt-in framing restored.** - The shared partial and every page that restates the rule say `pg-delta` is used when `[experimental.pgdelta] enabled = true` is present, `migra` otherwise. - Diff engines page: "Which engine" describes `init` writing the setting and existing projects staying on `migra` until they add it; the procedure is "Switch an existing project to `pg-delta`" again with "add the setting" as step 1 (pinned anchor unchanged). The sentence claiming `SUPABASE_EXPERIMENTAL_PG_DELTA` is ignored is removed, since that was also tied to the CLI change. - Config reference: `experimental.pgdelta.enabled` default `false` with the opt-in description. Commands spec: `--use-migra` default `true`, `--diff-engine` default `migra`, and the `db diff`, `db pull`, and `--declarative` descriptions describe both engines by config. - Declarative AI prompt: prerequisites tell the reader to ensure the section is present, with `--experimental` as the single-run alternative. **Kept from #50220 and this branch** because they hold regardless of the default: the `schema_paths` warning fires only when the setting lists paths; RLS policies on `auth` tables are captured; the migra initial pull's `pg_dump` skips managed schemas and the diff pass that follows appends the trigger and policy changes; and the four CodeRabbit fixes (scoped reordering claim, engine-qualified baseline claim with a link to the legacy section, `--no-apply` on the walkthrough `sync` commands, configurable declarative directory). ## Additional context Prettier passes with the repo config and both spec YAML files parse. Eight files, 36 lines changed in the reframing commit; five files, eight lines in the CodeRabbit commit. The companion [supabase/cli#6557](supabase/cli#6557) is unaffected: it updates the `db pull` reference examples and overlay without asserting a default. 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_0191XKFXEZ8kHsMNWHAaKgE2 --------- 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
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.
Summary
The docs-spec generator (
apps/cli/scripts/generate-docs-spec.ts, published intosupabase/supabasebypublish-docs-spec.ts) builds the publicdb pullreference fromapps/cli/docs/supabase/db/pull.mdandapps/cli/docs/templates/examples.yaml. Both still described the pre-pg-delta flow, so the next publish would overwrite the hand-edited reference in supabase/supabase#49889 and supabase/supabase#50220 with stale text. This carries the same content into the generator inputs.examples.yaml,supabase-db-pull:supabase db pull --schema auth,storageagain to diff them." line. The CLI no longer prints it and no longer excludes those schemas from the baseline.--debughint.--schema public,extensions, sinceauth,storageis no longer the motivating case.pull.mdoverlay:_1/_2suffixes the migration writer produces (${name}${suffix}, suffix from pg-delta'srenderPlanFiles) instead of the older_schema_changes/_after_enum_valuesunit-name scheme, and mention the-- pg-delta: transaction=falsedirective on non-transactional units.authtable, and thestorage/realtimepolicy surfaces.Deliberately not touched here: the paragraphs #6391 rewrites (engine default, initial-pull behavior, debug bundle path) and the
--db-urldirect-versus-pooler advice, which the docs PR and this overlay currently disagree on and which needs a CLI-team call. Text only, no behavior change.Linked issue
Follow-up to #6391 (docs alignment); no separate issue.
open-for-contributionlabel (or I'm a Supabase maintainer).Checklist
fix(cli): …).examples.yamlids and overlay paths, pass.pnpm check:allpasses; relevant package tests pass for every touched workspace, andpnpm types:checkpasses for each touched TypeScript workspace (or workspace declaring it). Run locally:oxfmt --checkon the two files and thesrc/docs/unit tests inapps/cli. The fullcheck:allis left to CI.🤖 Generated with Claude Code
https://claude.ai/code/session_0191XKFXEZ8kHsMNWHAaKgE2