Repository navigation
chore(repo): sync develop into next - #7401
Merged
Merged
Conversation
## TL;DR fixes `config push` failing when the oauth server path changes or the server is turned on or off ## whats improved/fixed? the api only accepts `oauth_server_enabled` and `oauth_server_authorization_path` together, but `config push` sent just the changed one ## how? send the missing one too, using the linked project's current value (so enabling keeps a stored custom path), else the config value or default ## ref: - closes: #7087
This bumps storage from v1.84.33-r0 to v1.84.34-r0. https://github.com/supabase/slim-services/releases/tag/storage-v1.84.34-r0 Planned after supabase/slim-services published v1.84.34-r0. This branch is rewritten from develop whenever a newer relevant release arrives. Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
This bumps postgres from 17.11.0.007-r0 to 17.11.0.008-r0. https://github.com/supabase/slim-services/releases/tag/postgres-17.11.0.008-r0 Planned after supabase/slim-services published 17.11.0.008-orioledb-r0. This branch is rewritten from develop whenever a newer relevant release arrives. Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
This adds postgres 17.11.0.008-orioledb-r0 as a new release line. https://github.com/supabase/slim-services/releases/tag/postgres-17.11.0.008-orioledb-r0 Planned after supabase/slim-services published 17.11.0.008-orioledb-r0. This branch is rewritten from develop whenever a newer relevant release arrives. Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
This bumps storage from v1.84.34-r0 to v1.84.35-r0. https://github.com/supabase/slim-services/releases/tag/storage-v1.84.35-r0 Planned after supabase/slim-services published v1.84.35-r0. This branch is rewritten from develop whenever a newer relevant release arrives. Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
This bumps storage from v1.84.35-r0 to v1.84.36-r0. https://github.com/supabase/slim-services/releases/tag/storage-v1.84.36-r0 Planned after supabase/slim-services published v1.84.36-r0. This branch is rewritten from develop whenever a newer relevant release arrives. Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
This bumps realtime from v2.149.1-r0 to v2.149.2-r0. https://github.com/supabase/slim-services/releases/tag/realtime-v2.149.2-r0 Planned after supabase/slim-services published v2.149.2-r0. This branch is rewritten from develop whenever a newer relevant release arrives. Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
…) (#7388) ## TL;DR `supabase link` now works with a project scoped token that can't read secret API keys, so CI can link and run `db push` with least privilege ## whats improved/fixed? link always asked for the secret keys with `reveal=true` so a token without API Key Secrets read got a 403 and link failed with `Authorization failed for the access token and project ref pair` those keys only feed the optional service version checks, so the whole command was blocked for nothing ## how? a 403 there now prints a warning naming the missing permission, skips those checks and still writes the link any other failure still fails, and `link --help` now lists `api_gateway_keys_secret_read` as optional <details> <summary>visual rep</summary> ```mermaid flowchart TD link["supabase link"] --> project["GET /v1/projects/{ref}"] project --> keys["GET api-keys?reveal=true"] keys -- "200" --> probes["service version checks"] probes --> saved["link saved"] keys -- "403 before" --> failed["link fails<br/>db push --linked has no project"] keys -- "403 now" --> warn["warning names API Key Secrets read<br/>version checks skipped"] warn --> saved keys -- "401, 404, other" --> error["link fails as before"] saved --> push["db push --linked<br/>connects with the database password"] ``` </details> ## ref: - closes: #6392 - closes: #7165
…om/schemas (#7366) ## Summary The config, project-config and `supabase.lock` schemas declared draft 2020-12, and their `$id`s pointed at `supabase.com/docs/cli/...`, which 404s. Taplo (Even Better TOML) doesn't support anything newer than draft-07, and the schemas only use keywords draft-07 already has. So this moves all three to draft-07, with `$id`s at the URLs they'll be hosted at. - `toPublishedJsonSchemaDocument` and the lock schema now go through Effect's `JsonSchema.toDocumentDraft07`. That converter turns `$defs` into `definitions`, rewrites the refs, and throws on anything draft-07 can't represent rather than dropping it - The `$id`s move to `https://supabase.com/schemas/{config,project-config,supabase-lock}/v1.json`. Nothing is served there yet. CLI-2865 sets up the path in supabase/supabase and CLI-2864 publishes to it on stable releases - The committed copies move from `apps/docs/public/cli/*.schema.json` to `apps/docs/public/schemas/<name>/v1.json`. That's the same layout as the hosted URLs, so the publisher can copy the folder across as-is - `supabase.lock` keeps being written with its original `$schema` value, because older CLIs check that field as a literal and would reject anything else. Reads also accept the hosted URL (`HOSTED_LOCK_SCHEMA_URL`), so a later release can switch writes over once enough CLIs read it - New `apps/cli/scripts/published-schemas.unit.test.ts` runs in the existing unit job. It fails when a committed schema: - uses a keyword newer than draft-07 - has a ref to `#/$defs/` - has an `$id` that doesn't match its file path - has drifted from what the source renders - The lock schema committed on develop was already behind the `Lock` schema. Regenerating it also brings in the current shape (no `ArtifactPin`). The per-service `ServiceLock` schemas render identically, so the published schema collapses them into one definition ## Schema shape change `@supabase/config/schema.json` and `@supabase/config/project-schema.json` now declare draft-07 (`http://json-schema.org/draft-07/schema#`) and the new `$id`s. `CLI_CONFIG_SCHEMA_URL` and `PROJECT_CONFIG_SCHEMA_URL` change value to match. The schema bodies are otherwise unchanged. If you validate them with a 2020-12-only validator such as `Ajv2020`, switch to a draft-07 one. Code that uses those constants as a default `$schema` now writes the new URL. Existing `$schema` values in user config files aren't changed. ## Linked issue Closes CLI-2856
…LI-2576) (#7382) ## TL;DR adds the gateway routes and forwarded headers the stack still lacked next to the legacy backend, so Studio's GraphiQL works on the stack ## whats introduced? the stack's api port now serves the routes the legacy backend had - `/graphql/v1`, adding `Content-Profile: graphql_public` only when the client sends none - `/rest-admin/v1` and `/.well-known/oauth-authorization-server` - `/pg/`, `/analytics/v1/` and `/pooler/v2/`, each while its service runs `/auth/v1/verify`, `/callback` and `/authorize` skip the api key rewrite, like the legacy backend gateway routes send `X-Forwarded-Proto`, `X-Forwarded-Host`, `X-Forwarded-Port`, `X-Forwarded-Path` and `X-Forwarded-Prefix` with the legacy values and replace any client sent ones, while each service's own port stays unchanged ## ref - extends: #7345
The `Detect unmirrored images` job in `mirror-template-images.yml` checks `public.ecr.aws` without logging in. Anonymous ECR Public pulls share a per-IP data quota with other GitHub-hosted runner users. That quota is often already used up, so most develop pushes fail with `429 toomanyrequests: Data limit exceeded` on every ECR target, and retrying doesn't help. This gives the detect job the same auth as the mirror job (`cli-go-mirror-image.yml`): `id-token: write`, assume `PROD_AWS_ROLE` in `us-east-1`, and log in to `public.ecr.aws`. The presence check itself is unchanged. Fixes CLI-2900. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
#7369) ## Summary If a `supabase start` dies after Docker creates the database container but before it starts it, the container is left in Docker's `created` state. That can happen if the process is killed, a port is already taken, or a second `start` rolls back the first one's containers. Every `supabase start` after that printed `supabase start is already running.` and then failed with `container is not running: created`. The way out was to remove the container by hand, and nothing pointed you there. Looking into it turned up three more problems along the same path: - The leftover volume never gets set up. `start` decided whether to run the first-run setup (schema, roles, migrations, seed) purely on whether the database volume already existed. A leftover volume that Postgres never initialised still exists, so after `supabase stop` and `supabase start` the setup was skipped and the stack came up without `supabase_migrations` or any of the project's migrations. - Two starts on one project break each other. When one fails, its rollback prunes the project's containers and network by label, including the ones the other start is still bringing up. Usually both fail, and they can leave behind exactly the `created` container above. - `db start` only checked that the database container existed. For a stopped or never-started one it printed `Postgres database is already running.` and exited 0 with Postgres down. The local database auto-start in `db schema declarative generate` and `sync` used the same check, skipped the start and then failed to connect. This fixes all of them. ### What changes - `start` recovers a `created` database container the same way it already recovers an `exited` one. It removes the project's containers and network, keeps the volumes, and brings the stack up again. - A database container that isn't running and can't be recovered (an unknown state, or Bitbucket Pipelines) now fails with `<container> container is not running: <state>` and suggests `supabase stop`. It no longer prints `supabase start is already running.` first. - `start` and `db start` check whether a reused volume was ever initialised. Between `docker create` and `docker start` they run `docker cp <container>:/var/lib/postgresql/data/PG_VERSION -`, which reads through the volume mount while the container is still stopped. The Postgres image runs `initdb` when `PG_VERSION` is missing, so a missing file means the volume is uninitialised. In that case the first-run setup runs and bucket seeding happens as on a fresh volume, and a failed bring-up prunes the volume like it does for a fresh one. Only Docker's or Podman's own message for a missing `PG_VERSION` counts as uninitialised. Any other outcome, including a connection error, is treated as initialised, so an ambiguous probe never runs setup over real data. - `start` and `db start` take a per-project lock at `$SUPABASE_HOME/locks/start-<project_id>.lock`. It's held through bring-up and rollback. A second start on the same project prints `Waiting for another supabase start for this project to finish...` and waits for the first, up to 10 minutes, before failing with `LocalStackStartBusyError`. If the lock file can't be created, the start carries on without it rather than failing. `stop` doesn't take the lock. - `db start` and the declarative auto-start now read the container's state as well as whether it exists. A database container that isn't running is removed on its own with `docker container rm -f`, keeping the volume, and brought up again. The `PG_VERSION` check above decides whether setup runs. The project's other containers are left alone, since `db start` only manages the database. In Bitbucket Pipelines they fail with the same not-running error as `start` instead. `db reset` and `db diff` still only check that the container exists, since `db reset` recreates it anyway. - If `db start` fails, it now rolls back only what it creates: the database container, the database volume when this run created it or found it uninitialised, and any project network nothing else is using. It used to remove every container in the project and, on a fresh volume, prune every unused project volume, so a failed recovery could take down the rest of a running stack. A stopped database with `--from-backup` is refused before anything is removed. - Under `--debug`, a missing profile file now logs `No profile file at <path>; using the default profile.` instead of the raw file-not-found error. That line was the only thing in the original report that looked like an error, and it wasn't one. ### Not covered - If `start` is killed after Postgres has started running `initdb` but before the CLI's setup finishes, the volume has `PG_VERSION`, so the next start treats it as initialised and skips setup. That's the same as before this change. Catching it would need a marker written once setup completes. I'd rather not guess at that from schema contents, since a project with no migrations looks the same as an unfinished one. ## Linked issue Closes #7344 (CLI-2876)
Adds a non-blocking job that compares the CLI build of each ready pull
request into `develop` with a build of the `develop` commit it branches
from, without Docker, a database, or the network. It writes a job
summary that leads with the answer ("no changes found" or "N things to
check"), then one plain-words line per flag (including when a command
that made no Management API calls starts making them), a before/after
timing table per command, API call counts, binary size, and a collapsed
section with timing ranges, per-command API calls, and the slowest
phases for commands that moved.
The first push to a pull request from this repository benchmarks and
posts one comment with the same report, tagged with a hidden marker.
Later pushes skip the benchmark while that comment reports a result, and
the job summary says so. Pull requests from forks have a read-only
token, so they get the job summary only and benchmark every push.
A maintainer can comment `/bench` to run the benchmark again on the pull
request's current head commit. The command re-runs that commit's
workflow run (the same as "Re-run all jobs" in the Actions UI), and the
re-run updates the comment in place. An eyes reaction on the `/bench`
comment means GitHub accepted the re-run; the result arrives as the
updated benchmark comment, whether it succeeded or failed. If nothing
can be re-run, the pull request gets a reply saying why: a benchmark is
already running, the run is older than 30 days, GitHub refused the
re-run, or there is no run for the commit. The comment keeps a collapsed
"Previous runs" list (commit, time, headline, link; up to 20) in a
hidden marker. Only the repository owner and people with write access
can run it, and only on open, non-draft pull requests into `develop`
from this repository. The whole comment must be exactly `/bench`; any
other comment is ignored. Comment-triggered workflows run from the
default branch, so `/bench` starts working only after this merges to
`develop`.
A pull request that changes none of the benchmarked paths, or more than
the 300 files GitHub's path filter inspects, gets no run, so `/bench`
replies that there is none.
- `apps/cli/scripts/bench-cli.ts` gains `--workloads <manifest>` and
`--api-url`. Every launch gets a profile file pointing at a local replay
server (the profile is the CLI's only API redirect), and the harness
resets the server's request log and scenario before each launch. API
calls are counted from HTTP client spans in the trace and cross-checked
against the server's request log.
- `apps/cli/scripts/bench-report.ts` holds the report schemas and pure
analysis; `bench-summary.ts` renders the Markdown for the job summary
and the comment; `replay-control.ts` is the client for the replay
server's control API.
- `apps/cli/bench/workloads.pr.json` lists the workloads. They were
chosen from command usage data, ranked and filtered to commands that
need no Docker, database, network, or prompt; the method, query, and
caveats are in `apps/cli/docs/tracing-monitoring.md`.
- `apps/cli-e2e/scripts/replay-serve.ts` starts the existing replay
server standalone.
- `.github/workflows/cli-bench.yml` and `.github/scripts/cli-bench/` are
new. No existing workflow or action is edited.
The `/bench` job never checks out or runs pull request code: it runs
default branch code and only asks GitHub to re-run the existing
`pull_request` run, so benchmarks always execute in the pull request's
own run and cache scope, like any other pull request job. Permissions
are split by job: the job that decides whether to benchmark is
read-only, the `/bench` job is the only one with `actions: write`, the
job that builds and runs pull request code has read-only permissions,
and a separate job, the only `pull_request` job with comment-write
permission, downloads the rendered markdown, sanitizes it, and posts it;
it never runs pull request code. Whether the workflow token may call the
re-run endpoint is verified on the first `/bench` after merge; a refusal
is reported in the reply.
Pull request runs now measure the pull request head commit instead of
the test merge commit, so the commit shown in the report is the one that
was benchmarked.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
---------
Co-authored-by: Claude Sonnet 5.5 <noreply@anthropic.com>
This bumps postgres from 15.19.0.008-r0 to 15.19.0.011-r0. https://github.com/supabase/slim-services/releases/tag/postgres-15.19.0.011-r0 Planned after supabase/slim-services published 15.19.0.011-r0. This branch is rewritten from develop whenever a newer relevant release arrives. Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
This bumps postgres from 17.11.0.008-r0 to 17.11.0.011-r0. https://github.com/supabase/slim-services/releases/tag/postgres-17.11.0.011-r0 Planned after supabase/slim-services published 15.19.0.011-r0. This branch is rewritten from develop whenever a newer relevant release arrives. Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
This adds postgres 17.11.0.011-orioledb-r0 as a new release line. https://github.com/supabase/slim-services/releases/tag/postgres-17.11.0.011-orioledb-r0 Planned after supabase/slim-services published 15.19.0.011-r0. This branch is rewritten from develop whenever a newer relevant release arrives. Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
…#7379) ## TL;DR `supabase db advisors --local` / `--db-url` now lints the schemas that `[api]` in `config.toml` exposes, instead of whatever `pgrst.db_schemas` value the connection happens to carry. ## What's fixed? Splinter decides which schemas to lint by reading `pgrst.db_schemas`. The CLI never set it, so: - When it was unset, splinter fell back to `public`, and tables without RLS in other exposed schemas were never reported. - After any transaction on a backend had set it locally, the backend read `''` from then on. A pooled connection could then make `db advisors` report "No issues found" even with unprotected `public` tables. ## How? - `readDbToml` resolves `exposedSchemas` from `[api].schemas` and `[api].enabled` (empty when the Data API is off), with the `SUPABASE_API_SCHEMAS` / `SUPABASE_API_ENABLED` overrides and `[remotes.*]` precedence that `supabase start` uses. `DbConfigResolver` passes it on the `--local` and `--db-url` paths. - `db advisors` runs `select set_config('pgrst.db_schemas', $1, true)` inside its existing rollback transaction, before the lint setup. A Data API that is off sets `''`, so nothing is reported as exposed. - The `db query` agent-mode RLS advisory binds the same schema list as `$1::text[]` instead of reading the setting, and is skipped when the Data API is off. - `--linked` is unchanged; the platform sets the value for hosted projects. Behavior change: a malformed `SUPABASE_API_ENABLED` now fails config loading for commands that resolve the local database config, matching how `SUPABASE_AUTH_ENABLED` and `supabase start` already treat it. ## ref: - CLI-2824
This PR was automatically created to sync API types from the infrastructure repository. Changes were detected after refreshing `apps/cli-go/api/v1-openapi.yaml` from the latest spec from infrastructure, and `apps/cli-go/pkg/api` is regenerated from it. The snapshot diff is the upstream API change and is worth reading: it is marked `linguist-generated`, so GitHub collapses it behind a "Load diff" click rather than hiding it. Co-authored-by: supabase-cli-releaser[bot] <246109035+supabase-cli-releaser[bot]@users.noreply.github.com>
supabase-cli-releaser
Bot
requested review from
a team and
supabase-oss
as code owners
October 29, 2026 17:26
# Conflicts: # apps/cli-go/api/v1-openapi.yaml # apps/cli-go/pkg/api/types.gen.go # apps/cli-go/pkg/config/templates/Dockerfile # apps/cli/src/command-internal/db-bootstrap/local-db-running.ts # apps/cli/src/command-internal/db-bootstrap/start-local-database.ts # apps/cli/src/command-internal/db-config.layer.ts # apps/cli/src/command-internal/db-config.toml-read.ts # apps/cli/src/commands/config/push/push.handler.ts # apps/cli/src/commands/db/advisors/SIDE_EFFECTS.md # apps/cli/src/commands/db/advisors/advisors.integration.test.ts # apps/cli/src/commands/db/query/SIDE_EFFECTS.md # apps/cli/src/commands/db/query/query.handler.ts # apps/cli/src/commands/db/query/query.integration.test.ts # apps/cli/src/commands/db/schema/declarative/generate/SIDE_EFFECTS.md # apps/cli/src/commands/db/schema/declarative/sync/SIDE_EFFECTS.md # apps/cli/src/commands/db/shared/pgdelta.seam.integration.test.ts # apps/cli/src/commands/db/start/SIDE_EFFECTS.md # apps/cli/src/commands/link/SIDE_EFFECTS.md # apps/cli/src/commands/start/SIDE_EFFECTS.md # apps/cli/tests/helpers/command-mocks.ts # packages/config/AGENTS.md # packages/config/README.md
Contributor
Author
Claude resolved the merge of
|
| File | Resolution |
|---|---|
apps/cli/src/command-internal/db-bootstrap/local-db-running.ts |
Kept next's project-id lookup through CliConfigValues (optional resolvedProjectId) combined with develop's LocalDbState return value and collectText stdout parsing. isLocalDbRunning is now a wrapper with an optional project id that requires CliConfigValues. |
apps/cli/src/command-internal/db-bootstrap/start-local-database.ts |
Took develop's localDbState probe and stopped-container recovery, keyed by context.projectId. Fixed the dangling projectEnvValues reference to use context.projectEnvValues. |
apps/cli/src/command-internal/db-config.layer.ts |
Dropped develop's copy of the old --db-url block and added develop's exposedSchemas to the return value of next's resolveDbUrl. |
apps/cli/src/command-internal/db-config.toml-read.ts |
Kept next's CliConfigValues-based reader (no ENV_OVERRIDE_NAMES or envLookup). Ported develop's exposedSchemas as trimmed, deduplicated config.api.schemas, empty when config.api.enabled is false. |
apps/cli/src/commands/config/push/push.handler.ts |
Kept next's planResource structure and added develop's config argument to the encodeAuthBody call. |
apps/cli/src/commands/db/advisors/SIDE_EFFECTS.md |
Used next's tables, added develop's [api].enabled/[api].schemas read, and added the SUPABASE_API_SCHEMAS/SUPABASE_API_ENABLED rows in next's --remote wording. |
apps/cli/src/commands/db/advisors/advisors.integration.test.ts |
Kept next's boolean realLayers and added a realEnv option. develop's exposure tests now use the file-level temp workdir. |
apps/cli/src/commands/db/query/SIDE_EFFECTS.md |
Used next's tables plus develop's config read and the two API env-var rows. |
apps/cli/src/commands/db/query/query.handler.ts |
Merged imports: DbSession from next, ResolvedDbConfig from develop; dropped the unused PgConnInput. |
apps/cli/src/commands/db/query/query.integration.test.ts |
Kept next's resolveConnection mock and statement-recording queryRaw, and added develop's exposedSchemas parameter. The RLS branch is removed from queryRaw because develop moved the check to query. Changed develop's local: Option.some(true) to next's boolean local: true. |
apps/cli/src/commands/db/schema/declarative/generate/SIDE_EFFECTS.md |
Kept next's --reset trigger wording and added develop's local-database auto-start row. |
apps/cli/src/commands/db/schema/declarative/sync/SIDE_EFFECTS.md |
Kept next's reset-trigger wording and added develop's local-database auto-start row. |
apps/cli/src/commands/db/shared/pgdelta.seam.integration.test.ts |
The setup options now carry both develop's dbContainer and next's env. |
apps/cli/src/commands/db/start/SIDE_EFFECTS.md |
Kept next's wording without Go references and develop's term "db state probe". |
apps/cli/src/commands/link/SIDE_EFFECTS.md |
Kept next's table and output text, and added develop's 403-tolerant api-keys behavior and its warning line. |
apps/cli/src/commands/start/SIDE_EFFECTS.md |
Kept next's notes without Go references and added develop's not-running/stopped container behavior, created-status recovery and concurrent-start lock notes. |
apps/cli/tests/helpers/command-mocks.ts |
Took develop's POSTGRES_DATA_DIR import and next's projectRefLayer/commandTargetLayer imports, and dropped the removed remoteTargetLayer. |
packages/config/AGENTS.md |
Kept next's migration-check vocabulary note with develop's draft-07 schema dialect. |
packages/config/README.md |
Used next's table (cliCompat) with develop's draft-07 dialect for both schema files. |
apps/cli/src/commands/db/shared/pgdelta.seam.layer.ts |
Semantic fix: localDbState is called without the project id that only comes from the environment, so it resolves through CliConfigValues (next's approach). |
apps/cli/src/command-internal/db-bootstrap/local-db-running.integration.test.ts |
Semantic fix: next's project-id tests mocked the old containerExists method and now use develop's inspectContainer. develop's localDbState tests now provide CliConfigValues. |
apps/cli/src/command-internal/db-config.toml-read.unit.test.ts |
Removed develop's two tests for its custom env resolution (a remote api.enabled beating SUPABASE_API_ENABLED, and its error on a malformed value). next's config-value resolver replaced that code. The exposed-schema tests are kept. |
Deleted: apps/cli-go/api/v1-openapi.yaml, apps/cli-go/pkg/api/types.gen.go, apps/cli-go/pkg/config/templates/Dockerfile.
Decisions for @supabase/cli. Confirm them, or push a change to this branch:
- How should
api.enabledbe resolved for the exposed schemas, given develop's custom rules (a remote block beatsSUPABASE_API_ENABLED,invalid api.enablederror) and next'sCliConfigValuesresolver? Chose: Use next's resolver (config.api.enabled/config.api.schemas) and drop develop's two tests for its custom precedence and error message. Precedence and malformed-value errors now follow next's shared config resolver. - Should the declarative seam's
localDbStateprobe pass the project id fromcliSettings.projectId, which is read only from the environment? Chose: No. Following next, which removed this pattern fromstart-local-database, the probe resolves the project id throughCliConfigValues. That lookup still coversSUPABASE_PROJECT_ID. - develop modified three files under
apps/cli-go, which next deleted along with the whole Go CLI. Chose: Delete them. The postgres image bumps they carried are already inapps/cli/src/shared/services/Dockerfile.
Quick checks. pnpm run check:all --continue (exit 1), pnpm run test:unit (exit 1) failed on the merged tree.
Claude's fix. Fixed three merge conflicts: local-stack-start-lock.ts now imports DebugLogger from next's new shared/output/ location, the 14 db-toml goldens now include develop's new exposedSchemas field, and rollback.ts uses bare process.stderr instead of globalThis.process. The broken import should explain the type-check error, the test files that failed to load and the docs-spec script failure, but lint, knip and Effect-lint logs were cut off, so the next CI run has to confirm they pass.
Approve to fast-forward next once checks pass (workflow run).
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Superseded by a newer AI review
🤖 AI Review
Both independent reviews completed. The sole reported finding is refuted: --db-url remains a supported deprecated alias. Verification was static; dependencies are not installed.
Findings
No issues found.
Refuted findings (kept for transparency, not posted as review comments)
apps/cli/src/commands/db/advisors/advisors.live.test.ts:76(merge-resolution): Both newly synced advisor live tests invoke the removed --db-url flag, causing argument parsing to fail before the exposure behavior is exercised.
Refuted: --db-url is hidden and deprecated, not removed. target-selector.ts:187–192 maps it to a DbUrl selection, and resolve-target.ts:73–74 returns the database target. target-flags.unit.test.ts:108–119 explicitly covers parsing the deprecated aliases, while resolve-target.integration.test.ts:1013–1029 expects successful database targeting with a deprecation warning. The cited calls therefore do not fail argument parsing.
Stats
Claude findings: 0 · Codex findings: 1 · Confirmed: 0 · Refuted: 1 · Uncertain: 0
Models: claude-opus-5-5 + gpt-6.1-sol · Trigger: manual · Workflow run
This review runs once per PR. A maintainer can request another with a /ai-review comment.
Contributor
Author
Claude repair roundFixed the semantic conflicts behind the failing checks. Two db-config tests from develop now use next's resolveConnection/inputFor helpers. Five config push tests now pass the 0 findings fixed, 0 declined (workflow run). |
Contributor
Author
|
The repair commit moved the head to |
Contributor
There was a problem hiding this comment.
🤖 AI Review
Both independent reviews completed with zero findings. Reading the checked-out code and sync-resolution diff revealed no additional concrete issues introduced by the sync. Tests and type checks were not run because dependencies are absent.
Findings
No issues found.
Stats
Claude findings: 0 · Codex findings: 0 · Confirmed: 0 · Refuted: 0 · Uncertain: 0
Models: claude-opus-5-5 + gpt-6.1-sol · Trigger: manual · Workflow run
This review runs once per PR. A maintainer can request another with a /ai-review comment.
Contributor
Author
|
@supabase/cli Claude's repair rounds did not get this pull request green; please take over (workflow run). |
## TL;DR
stops `supabase db reset` randomly failing at `Initialising schema...`
## whats hurting the user(s)?
`supabase db reset` fails at random with `error running container: exit
1`, mostly in CI
it recreated the db while realtime kept running, so docker restarted
realtime mid reset and its migrations collided with the reset's own on
`schema_migrations_pkey`
## now fixed by:
storage, auth, realtime and the pooler are stopped before the db is
removed and started once at the end,
even when the reset fails...
```mermaid
sequenceDiagram
participant R as db reset
participant S as storage, auth, realtime, pooler
participant D as docker
participant DB as db
participant J as init jobs
Note over R,J: before
R->>DB: remove and recreate
DB--xS: connection lost
D->>S: restart (unless-stopped)
par
S->>DB: realtime migrations
and
J->>DB: realtime migrations
end
DB-->>J: schema_migrations_pkey
J-->>R: exit 1, reset fails
Note over R,J: now
R->>S: stop
R->>DB: remove and recreate
J->>DB: init migrations
R->>DB: your migrations + seed
R->>S: start once, reload kong
Note over R,S: same restart on failure or ctrl-c
```
## ref:
- closes: #6915
- closes: #6445
Hosted mutations now refuse in a non-TTY run without --yes, so the live suite's remaining unconfirmed setup and cleanup calls failed with "Confirmation required". Pass --yes to db query (write statements), migration repair and postgres-config delete in the live tests and helpers.
Coly010
approved these changes
Oct 29, 2026
This branch was successfully deployed
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.
Merging
developintonextconflicts. This branch starts at the tip ofdevelop(74d4774);nextis at7c6505f.Conflicting files:
apps/cli-go/api/v1-openapi.yamlapps/cli-go/pkg/api/types.gen.goapps/cli-go/pkg/config/templates/Dockerfileapps/cli/src/command-internal/db-bootstrap/local-db-running.tsapps/cli/src/command-internal/db-bootstrap/start-local-database.tsapps/cli/src/command-internal/db-config.layer.tsapps/cli/src/command-internal/db-config.toml-read.tsapps/cli/src/commands/config/push/push.handler.tsapps/cli/src/commands/db/advisors/SIDE_EFFECTS.mdapps/cli/src/commands/db/advisors/advisors.integration.test.tsapps/cli/src/commands/db/query/SIDE_EFFECTS.mdapps/cli/src/commands/db/query/query.handler.tsapps/cli/src/commands/db/query/query.integration.test.tsapps/cli/src/commands/db/schema/declarative/generate/SIDE_EFFECTS.mdapps/cli/src/commands/db/schema/declarative/sync/SIDE_EFFECTS.mdapps/cli/src/commands/db/shared/pgdelta.seam.integration.test.tsapps/cli/src/commands/db/start/SIDE_EFFECTS.mdapps/cli/src/commands/link/SIDE_EFFECTS.mdapps/cli/src/commands/start/SIDE_EFFECTS.mdapps/cli/tests/helpers/command-mocks.tspackages/config/AGENTS.mdpackages/config/README.mdTo resolve:
git fetch origin git switch sync/develop-into-next git merge origin/next # resolve the conflicts, then commit git push origin sync/develop-into-nextApprove to fast-forward
next; do not use the merge button.