chore: production deploy - #6229
Open
supabase-cli-releaser[bot] wants to merge 32 commits into
Open
Conversation
supabase-cli-releaser
Bot
commented
Aug 17, 2026
supabase-cli-releaser
Bot
commented
Contributor
- fix(deps): bump github.com/posthog/posthog-go from 1.22.0 to 1.23.0 in /apps/cli-go in the go-minor group across 1 directory (fix(deps): bump github.com/posthog/posthog-go from 1.22.0 to 1.23.0 in /apps/cli-go in the go-minor group across 1 directory #6176)
- test(stack): stabilize postgres persistence e2e (test(stack): stabilize postgres persistence e2e #6175)
- fix(cli): serialize container health checks (fix(cli): serialize container health checks #6149)
- fix(cli): restore serve argument (fix(cli): restore serve argument #6173)
- feat(cli): accept branch names and refs in supabase link (feat(cli): accept branch names and refs in supabase link #6168)
- feat(stack): isolate sibling worktrees and named stacks (CLI-2107) (feat(stack): isolate sibling worktrees and named stacks (CLI-2107) #6171)
- chore(stack): scope managed registry context reads (chore(stack): scope managed registry context reads #6181)
- fix(cli): align email paths (fix(cli): align email paths #6160)
- chore(cli): generate docs spec from TS (CLI-2171) (chore(cli): generate docs spec from TS (CLI-2171) #6157)
- feat(cli): discover function env files (CLI-2184) (feat(cli): discover function env files (CLI-2184) #6182)
- fix(cli): shrink the bundled Go binary to the proxied command subset (CLI-1970) (fix(cli): shrink the bundled Go binary to the proxied command subset (CLI-1970) #6162)
- chore(ci): bump linear/linear-release-action from 0.15.0 to 0.15.1 in the actions-major group (chore(ci): bump linear/linear-release-action from 0.15.0 to 0.15.1 in the actions-major group #6194)
- chore: sync API types from infrastructure (chore: sync API types from infrastructure #6195)
- feat(cli): suppress update notifier (CLI-1922) (feat(cli): suppress update notifier (CLI-1922) #6143)
- fix(cli): persist new migrations on Windows (CLI-2183) (fix(cli): persist new migrations on Windows (CLI-2183) #6192)
- fix(cli): surface setup errors (CLI-2187) (fix(cli): surface setup errors (CLI-2187) #6191)
- test(codeql): fixture syntax (test(codeql): fixture syntax #6189)
- feat(cli): add experimental --release-channel and --postgres-engine flags to projects create (CLI-2180) (feat(cli): add experimental --release-channel and --postgres-engine flags to projects create (CLI-2180) #6186)
- fix(cli): stream container secrets (CLI-2190) (fix(cli): stream container secrets (CLI-2190) #6201)
- fix(docker): bump the docker-minor group across 1 directory with 3 updates (fix(docker): bump the docker-minor group across 1 directory with 3 updates #6207)
- feat(stack): handle managed state across Git workspace changes (feat(stack): handle managed state across Git workspace changes #6202)
- fix(stack): settle managed identity recovery safely (fix(stack): settle managed identity recovery safely #6214)
- fix(cli): fail test db when no tests ran (CLI-2194) (fix(cli): fail test db when no tests ran (CLI-2194) #6210)
- fix(cli): stop buffering piped output (fix(cli): stop buffering piped output #6212)
- refactor(stack): simplify managed identity policy (refactor(stack): simplify managed identity policy #6216)
- fix(docker): bump supabase/realtime from v2.128.0 to v2.128.2 in /apps/cli-go/pkg/config/templates in the docker-minor group (fix(docker): bump supabase/realtime from v2.128.0 to v2.128.2 in /apps/cli-go/pkg/config/templates in the docker-minor group #6226)
- feat(cli): default database workflows to the bundled pg-delta engine (feat(cli): default database workflows to the bundled pg-delta engine #6102)
…n /apps/cli-go in the go-minor group across 1 directory (#6176) Bumps the go-minor group with 1 update in the /apps/cli-go directory: [github.com/posthog/posthog-go](https://github.com/posthog/posthog-go). Updates `github.com/posthog/posthog-go` from 1.22.0 to 1.23.0 <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/posthog/posthog-go/releases">github.com/posthog/posthog-go's releases</a>.</em></p> <blockquote> <h2>1.23.0</h2> <h2>Unreleased</h2> </blockquote> </details> <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/PostHog/posthog-go/blob/main/CHANGELOG.md">github.com/posthog/posthog-go's changelog</a>.</em></p> <blockquote> <h2>1.23.0</h2> <h3>Minor Changes</h3> <ul> <li>941d9ca: Support the <code>starts_with</code>, <code>not_starts_with</code>, <code>ends_with</code>, and <code>not_ends_with</code> property filter operators in feature flag local evaluation. Matching is case-insensitive and mirrors <code>icontains</code>, so flags using these operators no longer fall back to remote evaluation.</li> </ul> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/PostHog/posthog-go/commit/019af196c2dcc954849ebe39b8d71f8f7d05fd56"><code>019af19</code></a> chore: release v1.23.0 [version bump] [skip ci]</li> <li><a href="https://github.com/PostHog/posthog-go/commit/941d9caeadf6b09e4bd132207b5f4c6565089d13"><code>941d9ca</code></a> feat: support starts_with and ends_with operators in local evaluation (<a href="https://redirect.github.com/posthog/posthog-go/issues/264">#264</a>)</li> <li><a href="https://github.com/PostHog/posthog-go/commit/049b68276ebb0b7428450b22aaf822e5a56a1de4"><code>049b682</code></a> ci: clean up workflow warnings (<a href="https://redirect.github.com/posthog/posthog-go/issues/263">#263</a>)</li> <li>See full diff in <a href="https://github.com/posthog/posthog-go/compare/v1.22.0...v1.23.0">compare view</a></li> </ul> </details> <br /> [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- <details> <summary>Dependabot commands and options</summary> <br /> You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot show <dependency name> ignore conditions` will show all of the ignore conditions of the specified dependency - `@dependabot ignore <dependency name> major version` will close this group update PR and stop Dependabot creating any more for the specific dependency's major version (unless you unignore this specific dependency's major version or upgrade to it yourself) - `@dependabot ignore <dependency name> minor version` will close this group update PR and stop Dependabot creating any more for the specific dependency's minor version (unless you unignore this specific dependency's minor version or upgrade to it yourself) - `@dependabot ignore <dependency name>` will close this group update PR and stop Dependabot creating any more for the specific dependency (unless you unignore this specific dependency or upgrade to it yourself) - `@dependabot unignore <dependency name>` will remove all of the ignore conditions of the specified dependency - `@dependabot unignore <dependency name> <ignore condition>` will remove the ignore condition of the specified dependency and ignore conditions </details> Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
## TL;DR Stabilize the Postgres persistence e2e by checking only the Docker containers created during native stack startup. The test previously checked every matching container on the runner. A container left by another test could therefore cause a failure even when native startup used no Docker containers. Capture matching container IDs before startup and assert that no new IDs appear afterward. This follows the stack test suite's existing snapshot and diff pattern while preserving Docker startup and data persistence coverage... ## ref: spotted on: https://github.com/supabase/cli/actions/runs/31634963213/job/94242831412
## TL;DR fixes `supabase start` polling every booting service concurrently. <br> happened because the ts port used unbounded concurrency, while Go checked containers serially in start order. <br>The concurrent implementation could burst Docker subprocesses and exhaust the retry allowance sooner on constrained systems. <br>this restores Go’s behavior by running one health probe at a time and adds regression coverage for the ordering... ## ref: * closes #6112
## TL;DR Accept the legacy optional Function name positional argument for `supabase functions serve` in the ts cli... the command continues to serve all discovered Functions, matching Go behavior while restoring parser compatibility lost in the native port... ## ref: - closes #6170
## What kind of change does this PR introduce? Feature (legacy shell, TS-only QoL — no Go counterpart). ## What is the current behavior? `supabase link` only accepts a 20-character project ref via `--project-ref`. Linking to a preview branch means digging its project ref out of the dashboard. Once linked to a branch, every `branches` subcommand fails (the platform returns 403 for branch refs on the branches-management endpoints), and nothing in the CLI tells you which project or branch a workdir is linked to. Closes CLI-2167 ## What is the new behavior? **`supabase link` accepts branch names and refs** — new optional positional `[ref-or-branch]`, and `--project-ref` accepts a branch name/UUID too. Ref-shaped values (20 lowercase letters) always short-circuit as refs, so every currently-working invocation is unchanged; anything else resolves against the linked parent project's branches (parent chain: `SUPABASE_PROJECT_ID` → `supabase/.temp/linked-project.json` → `supabase/.temp/project-ref`, first valid wins — the cache file only ever holds a real non-404 project, which is what makes re-linking between branches work with no new persistent state). Env var and TTY prompt stay refs-only. A branch whose `project_ref` hasn't provisioned yet fails loudly instead of silently linking the parent. **`branches` subcommands survive branch links** — all 8 handlers resolve their parent-scoped ref through the same chain (explicit `--project-ref` still wins; prompt/error fallbacks unchanged). **Linked-state visibility** (agent-discovery oriented): - `supabase status` prints a `Linked Project:` block (Org/Project/Branch, name + ref) on stdout before any daemon work, so it shows even when status then fails; machine modes get additive `LINKED_*` env keys / `linked_*` keys / a nested `linked_project` object — including on the `--output-format json`/`stream-json` **failure** envelope via a new opt-in `MachineErrorContext` cell (inert for every other command; Go `-o` formats deliberately unchanged on failure). Resolution is lazy and token-optional — offline runs degrade to the known refs and never change status's own failure modes. - `branches list` marks the linked branch `(active)` in the human table (machine payloads unchanged); `projects list` marks the parent project when linked to a branch. **Telemetry**: branch links fire `cli_project_linked` with TS-only `linked_via: "branch"` + `parent_project_ref` (branch names never sent; `--project-ref` is only telemetry-safe when ref-shaped). Docs: `SIDE_EFFECTS.md` files and `docs/go-cli-porting-status.md` updated for every divergence. Related follow-up filed separately: CLI-2171 (reference docs are generated from the Go cobra tree, so TS-only surfaces like this positional don't reach the docs site).
…6171) Implements [CLI-2107](https://linear.app/supabase/issue/CLI-2107/state-isolate-sibling-worktrees-and-named-stacks-end-to-end): extends the managed-state baseline (#6152) so linked worktrees, ordinary Git checkouts, bare-repository worktrees, branches, and named stacks coexist without sharing mutable runtime state. All identity and isolation policy lives in `@supabase/stack/managed`; no CLI handler changes. ## Git identity storage - **Workspace inspection** (`managed/git.ts`): classifies primary checkouts, linked worktrees, bare-repo worktrees, and ordinary folders by parsing Git metadata files directly (`.git` file/dir, `commondir`, `HEAD`) — read-only inspection performs zero writes and needs no `git` binary. Repositories using the reftable ref backend are refused with a typed `UnsupportedGitWorkspaceError` instead of silently collapsing branch contexts (their `HEAD` compat stub always names `refs/heads/.invalid`). - **Project ID** lives in common-scope git config (`supabase.projectId` in `<commonDir>/config`), so all linked worktrees — including worktrees of a bare repository with no primary worktree — share it, and a fresh `git clone` receives new identity for free (clone copies no config). - **Checkout ID** lives in a versioned JSON marker under each checkout's own git directory (`<gitDir>/supabase-checkout.json`), so every worktree is an independent checkout. - **Branch context IDs** live in `branch.<name>.supabaseContextId` (common scope): worktrees on the same branch share a context, `git branch -m` carries the ID with the section rename, and branch deletion orphans the context without touching stack data. - Config claims use append-and-adopt-first-value (`git config --add`, re-read, adopt the immutable first value, idempotent collapse) with lock-contention retries — a plain set-then-reread protocol demonstrably loses claims under concurrency. - Identity is never inferred from remotes, branch names, commits, basenames, or path hashes. ## Registry schema v4 Branch contexts are project-scoped; detached and workspace contexts are checkout-scoped (partial unique index per checkout). Checkouts record their kind, and each checkout has exactly one canonical location keyed to the checkout **root** (starting from a nested subdirectory resolves and reuses the same location). The live-stack uniqueness keystone `(checkout_id, context_id, name)` is unchanged. The registry file is now `registry-v4.sqlite3`; as with v3, this unreleased POC has no data-migration path. ## resolveStack `resolveStack({ workspacePath, stackName?, operation: "start" | "status" })` is the single identity/decision path — `provisionOrdinaryStack`/`inspectOrdinaryWorkspace` are folded in, not layered over. `status` is strictly read-only (no markers, no config keys, no registry rows); `start` ensures identities and provisions through the existing pending→publish/operation-claim machinery. Interrupt-safety around claim creation was tightened so an op-boundary interrupt cannot leak a pending stack with a live operation claim. Stack names are validated as lowercase DNS labels before any write. `deleteStack`/`updateStack`/`inspectStack`/`listStacks` remain global-by-opaque-ID with no workspace resolution required, and projections now expose full IDs, checkout kind/path, context kind/branch locator, ports, and lifecycle so every sibling instance is deterministically distinguishable. ## Fixtures made executable The CLI-2102 worktree, bare-repo, named-stack, stack-name, and reclamation fixtures in `managed-stack-contract.ts` are now driven through the real service against **both** registry adapters using real git repos/worktrees in temp dirs. Symbolic fixture IDs are checked as equality/inequality relations (shared symbol ⇒ same real UUID, distinct symbols ⇒ distinct UUIDs), so editing fixture data changes test behavior. A three-sibling end-to-end proof (two worktrees + one named stack) shows distinct data roots and ports, and that a global delete-by-ID leaves the survivors' records, ports, and data untouched. ## Reviewer notes - `when` actions expressed as CLI argv in fixtures are driven through their managed-API equivalents; CLI command wiring and human/JSON rendering are later issues, per the issue's implementation boundary. - Duplicate-copy claims, branch-copy collisions, and moved-worktree recovery remain with CLI-2108. - The fixture `identity.valid-stack-names-resolve-deterministically` names a `resolveStackNames` method that does not exist; it is honestly expressed as per-name read-only `resolveStack` calls (zero-write witnessed). A fixture cleanup could rename the method or add the missing `stack` given-facts. - Pre-existing (at HEAD, not introduced here): a failed managed-service handle acquisition leaks the opened SQLite handle; tracked as a follow-up outside this PR. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
## Summary - Scope managed stack projection reads to the resolved project, checkout, and context before hydrating port assignments. - Share one pure context-registration decision across the SQLite and in-memory adapters while keeping each adapter transactionally authoritative. - Preserve global listing behavior, deterministic ordering, tombstone handling, and existing context identity semantics. ## Linked issue [CLI-2185](https://linear.app/supabase/issue/CLI-2185/stack-scope-managed-registry-reads-and-centralize-context-policy) ## Reviewer context This builds on the managed-state APIs introduced by #6171, which is now merged. The branch has been rebased onto develop, so the PR diff is limited to the focused CLI-2185 change.
## TL;DR Resolve Auth email template and notification `content_path` values against the same project-root base in the native TypeScript CLI. <br>this removes the asymmetric path behavior while keeping config validation, config push, Kong mounts, and generated configuration consistent.. ## Ref: * closes #6159
## TL;DR re-points CLI reference docs generation at the TypeScript command tree, replacing the retired Go generator with `scripts/generate-docs-spec.ts`. ## What's introduced? - `scripts/generate-docs-spec.ts`, walking the legacy Effect command tree and merging the overlays and examples under `apps/cli/docs` into the reference spec - docs-local introspection helpers and unit tests - build time validation of the static tables, so command or flag renames fail loudly Purely additive, no existing source files modified. ## Why was it needed? - the reference was generated from the Go command tree, which the Go CLI deprecation deletes - TS only additions never appeared on the docs site The output was parity checked against the Go generator before its removal: all 135 command ids, anchors, flags and defaults match, and TS only surfaces like `completion` and `issue` now appear. ## ref: - stacks on top of: #6155 - closes: CLI-2171
## TL;DR Automatically discover `supabase/functions/<function-name>/.env` files when running `supabase functions serve`. Without `--env-file`, `supabase/functions/.env` continues to provide shared values, while each Function's `.env` overrides matching values for that Function only. An explicit `--env-file` remains the highest-priority source and disables automatic discovery... This is scoped to `functions serve` `supabase start` retains its existing behavior(will consider it as a followup, if needed) ## Ref: - closes: #6179 super thanks! to @Bohooslav 💚
…(CLI-1970) (#6162) ## Summary The M9 capstone ([CLI-1970](https://linear.app/supabase/issue/CLI-1970/shrink-the-bundled-go-binary-to-the-pg-schema-only-subset-and-rescope)), expanded per review: the bundled `supabase-go` is cut down by **deletion** (not build flags) to exactly the `LegacyGoProxy` command surface, the last non-proxy Go spawn (the pg-delta seam) is **ported to native TypeScript**, the go-vs-ts parity harness is retired, and the Go-port provenance scaffolding (comments, SIDE_EFFECTS framing, docs) is swept out of the TS tree. ### The residual Go surface (exhaustive) `LegacyGoProxy` is now the **only** code path that spawns `supabase-go`: - `db diff` — kept for `--use-pg-schema` (in-process `stripe/pg-schema-diff`, CLI-1960) - `db pull` — kept for `--experimental` structured dump (multigres DDL parser, CLI-1957) - `db branch create|delete|list|switch`, `db remote changes|commit`, `gen keys` — Go-deprecated wrapped commands kept indefinitely (CLI-1964 cancelled) - `functions download` — kept for the hidden `--legacy-bundle` path (CLI-1963) ### What changed - **Go deletion**: main module 138 → 38 first-party packages (100 deleted; 321 files, ~29.5k LOC). Kept: `pkg/` (independently tagged module; audited — all 13 packages remain reachable from the trimmed binary or its tests) and `tools/listdep` (used by `cli-go-mirror.yml`). Deleted-source pin: `7b469f5b3`. - **pg-delta seam ported native** (was the parity audit's blocker): `db schema declarative generate|sync` no longer spawn `supabase-go db schema declarative __catalog`/`db start` — the seam layer now composes the existing native primitives (`legacySetupShadowDatabase`, `legacyExportCatalogPgDelta`, hoisted `legacyStartLocalDatabase`) in-process, preserving catalog cache filenames (shared with the Go binary's own pull path), banner ordering, and the `LegacyDeclarativeShadowDbError` contract. The two Go seam commands were then deleted. - **Parity harness retired**: `runParity`/`testParity` + the `go` `CLITarget` removed (~127 call sites); `live-e2e.yml` matrix is ts-legacy-only; `cli-go-ci.yml` `link` job removed (not a required check — verified against the develop ruleset). - **Provenance sweep**: Go-parity comments removed across `src/legacy` (~700 files) and all 103 `SIDE_EFFECTS.md`; live-delegation documentation (the proxy commands, telemetry co-existence, shared pgdelta cache format) kept. Go template/testdata fixtures the unit tests depended on are vendored into `apps/cli`. - **New guard**: `go-binary-surface.e2e.test.ts` runs every TS-buildable argv against the built Go binary (help resolution + flag-surface + negative controls), so a future trim that orphans a spawn path fails CI instead of shipping — regression-tested by deliberately breaking the binary. ### Binary sizes (release build: `-trimpath -ldflags "-s -w"`, CGO_ENABLED=0) | Platform | supabase-go | |---|---| | darwin-arm64 | 40.1 MB | | darwin-x64 | 42.6 MB | | linux-arm64 (+musl copy) | 39.1 MB | | linux-x64 (+musl copy) | 41.8 MB | | windows-arm64 | 39.5 MB | | windows-x64 | 42.8 MB | Progression: 97–103 MB → ~47–52 MB (CLI-1966) → **39.1–42.8 MB**. Tarballs 37.9–52.9 MB, deb/rpm/apk 52.3–54.1 MB. Remaining weight is intentionally-retained deps (multigres parser, pg-schema-diff, Docker client for shadow DBs, pgx, Management API client). ### Accepted behavioral divergence `db remote changes|commit --password <p>` now beats `SUPABASE_DB_PASSWORD` (previously env silently won — a latent artifact of Go's package-wide last-`viper.BindPFlag` semantics landing on the deleted `projects.go`). Documented in `go-cli-porting-status.md` § behavioral divergences; ruled the intended behavior in the parity audit. ### Verification - Go: build/vet/full test suite green (32 packages); every retained proxy argv shape (all flags + all 10 global flags) parses on the trimmed binary; dropped commands correctly fail. - TS: full core suite green (**446 files / 7,613 tests**); types/lint/fmt/knip green across `supabase`, `@supabase/cli-e2e`, `@supabase/cli-test-helpers`. - Full release artifact build (`build.ts --shell legacy`) clean across all 8 platform packages + tarballs + deb/rpm/apk. - Internal review: go-parity-auditor (binary-level before/after diffing — caught the seam, now ported; flagged the DB_PASSWORD divergence, accepted + documented) and engineer-reviewer (both blockers resolved: seam ported, unit suite green with vendored fixtures; minors addressed — orphaned examples README deleted, harness `CLI_HARNESS_TARGET` fail-fast guard, doc counts corrected). ## Linked issue Closes CLI-1970 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: avallete <andrew.valleteau@supabase.io> Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
… the actions-major group (#6194) Bumps the actions-major group with 1 update: [linear/linear-release-action](https://github.com/linear/linear-release-action). Updates `linear/linear-release-action` from 0.15.0 to 0.15.1 <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/linear/linear-release-action/releases">linear/linear-release-action's releases</a>.</em></p> <blockquote> <h2>v0.15.1</h2> <h2>What's Changed</h2> <ul> <li>Expose the CLI --issue-pattern flag as an issue_pattern input by <a href="https://github.com/RomainCscn"><code>@RomainCscn</code></a> in <a href="https://redirect.github.com/linear/linear-release-action/pull/56">linear/linear-release-action#56</a></li> <li>Release v0.15.1 by <a href="https://github.com/RomainCscn"><code>@RomainCscn</code></a> in <a href="https://redirect.github.com/linear/linear-release-action/pull/57">linear/linear-release-action#57</a></li> </ul> <p><strong>Full Changelog</strong>: <a href="https://github.com/linear/linear-release-action/compare/v0.15.0...v0.15.1">https://github.com/linear/linear-release-action/compare/v0.15.0...v0.15.1</a></p> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/linear/linear-release-action/commit/17b8c24f8ceb2b98cabaf1965ff83c55dd596fac"><code>17b8c24</code></a> Release v0.15.1 (<a href="https://redirect.github.com/linear/linear-release-action/issues/57">#57</a>)</li> <li><a href="https://github.com/linear/linear-release-action/commit/cb0977c25f7e16b4ea2e89d9f71841e3f887dea4"><code>cb0977c</code></a> Expose the CLI --issue-pattern flag as an issue_pattern input (<a href="https://redirect.github.com/linear/linear-release-action/issues/56">#56</a>)</li> <li>See full diff in <a href="https://github.com/linear/linear-release-action/compare/af56a9a388625921f3757a2f988e4d7aca958377...17b8c24f8ceb2b98cabaf1965ff83c55dd596fac">compare view</a></li> </ul> </details> <br /> [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- <details> <summary>Dependabot commands and options</summary> <br /> You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot show <dependency name> ignore conditions` will show all of the ignore conditions of the specified dependency - `@dependabot ignore <dependency name> major version` will close this group update PR and stop Dependabot creating any more for the specific dependency's major version (unless you unignore this specific dependency's major version or upgrade to it yourself) - `@dependabot ignore <dependency name> minor version` will close this group update PR and stop Dependabot creating any more for the specific dependency's minor version (unless you unignore this specific dependency's minor version or upgrade to it yourself) - `@dependabot ignore <dependency name>` will close this group update PR and stop Dependabot creating any more for the specific dependency (unless you unignore this specific dependency or upgrade to it yourself) - `@dependabot unignore <dependency name>` will remove all of the ignore conditions of the specified dependency - `@dependabot unignore <dependency name> <ignore condition>` will remove the ignore condition of the specified dependency and ignore conditions </details> Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
This PR was automatically created to sync API types from the infrastructure repository. Changes were detected in the generated API code after syncing with the latest spec from infrastructure. Co-authored-by: supabase-cli-releaser[bot] <246109035+supabase-cli-releaser[bot]@users.noreply.github.com>
## TL;DR Adds `SUPABASE_NO_UPDATE_NOTIFIER` to suppress the `A new version of Supabase CLI is available` notice, following the same convention... ## What's introduced? - A native port of the upgrade notice to the legacy TypeScript shell: same message bytes, same `supabase/.temp/cli-latest` ten hour cache, `--workdir` aware, with `--debug`/`SUPABASE_DEBUG` diagnostics for failed fetches and cache reads. - One switch for both sides: the Go sidecar honors the same variable, and the legacy shell suppresses its Go children so the notice prints exactly once. - Hardening: a symlink anywhere in the cache path disables caching instead of being written through, color is gated for `NO_COLOR` and piped stderr, and a Ctrl-C or CI timeout during the bounded trailing check no longer turns a successful command into exit 130, through the compiled binary and the npm shim alike. ## Why is it needed? The notice only came from the bundled Go sidecar, so it appeared on delegated commands, was missing from native ones, and could not be turned off. Users who pin the CLI version on purpose (Nix, lockfiles, CI images) had no way to silence it. ## ref: - closes: CLI-1922 - closes: #5853
## TL;DR Ensure `supabase migration new` creates the migration file before reporting success, including on affected Windows environments... The command now explicitly creates or truncates the migration before streaming piped input,<br> following the existing `db dump` and `db pull` pattern.<br>it also kinda verifies that the file exists before emitting success.. ## Ref * Closes #6174
## TL;DR Fixes filesystem errors during `functions serve` setup which were being surfaced as the generic `An error occurred in Effect.tryPromise` message. We already applied a similar fix in [#5904](#5904) for the same generic error, so it is worth preserving the underlying cause here as well. This also prevents a secondary cleanup failure from masking the original setup error. ## Ref - Closes #6185
clears these warnings: <img width="1279" height="879" alt="image" src="https://github.com/user-attachments/assets/b377a39b-932e-4c8d-961d-8249515e5576" />
…lags to projects create (CLI-2180) (#6186) ## What Adds two hidden, `--experimental`-gated flags to the legacy `supabase projects create` command: - `--release-channel <internal|alpha|beta|ga|withdrawn|preview>` - `--postgres-engine <15|17|17-oriole>` (this is what enables creating managed **OrioleDB** projects, CLI-2180) ## Why The Management API's `POST /v1/projects` accepts `release_channel` and `postgres_engine`, but the public OpenAPI spec deliberately hides both fields by typing them as `{"deprecated": true, "type": "null"}` — which our codegen faithfully reproduced, so the typed client rejected real values before the request ever left the CLI. Context: [Slack thread](https://supabase.slack.com/archives/C07E5GFAHTM/p1786527782451559) — needed to create OrioleDB projects and `internal`-channel projects (e.g. on staging) from the CLI. ## How - **`packages/api`**: two test+replace pairs in `scripts/openapi-overrides.json` (the existing RFC 6902 spec-patch pipeline) restore the real enum types on `V1CreateProjectBody`, mirrored into the committed spec and regenerated offline. The `test` ops fail loudly on the next spec download if upstream changes these fields' shape (e.g. when they get exposed officially), so the override can't silently rot. - **`apps/cli`**: both flags are `Flag.withHidden` and gated through the shared env-aware `legacyRequireExperimental` (so `SUPABASE_EXPERIMENTAL=true` also satisfies the gate, consistent with every other experimental command). Choice lists derive from the generated schema literals (`V1CreateAProjectInput.fields.*.schema.literals`) so they can't drift on regen. Both flags are TS-only (no Go equivalent), disclosed in `SIDE_EFFECTS.md` and `docs/go-cli-porting-status.md`. They're `Flag.choice`, so telemetry auto-treats them as safe enum flags — no `safeFlags` change. - The new value-consuming flags are registered in `VALUE_CONSUMING_LONG_FLAGS` (CLI-1896 completeness check caught this). ## Notes for reviewers - Server-side gating still applies: non-GA channels require the org's `allowed_release_channels` to include the requested channel in production (`internal` is auto-allowed on staging), enforced by `runProjectCreationFlow` in the platform. - Flags stay hidden/experimental deliberately since upstream hides the fields on purpose; once the platform exposes them officially in the public spec, the overrides will fail their `test` ops on regen and can simply be deleted, and the flags un-hidden. Fixes: CLI-2180 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
## TL;DR Stream container secrets as a single in-memory tar archive through `docker cp - <container>:/` instead of staging plaintext files under the host’s `/tmp`. ## What’s fixed? Strictly confined Docker installations, including Docker Snap, cannot necessarily see files created in the CLI process’s `/tmp`. This caused `supabase start` to fail while copying the Postgres root key: `failed to copy secret file into container: lstat /tmp/supabase-start-secret-*: no such file or directory` Secrets are now archived in memory and streamed over stdin after `docker create` and before `docker start`. They retain their exact container paths and `0644` permissions without touching the host filesystem or subprocess argv. ## Why was it biting? The Go CLI passed secret content through the Docker Engine API as part of the container configuration, then materialized it inside the container before starting the service. It never depended on a host path being visible to the Docker client. The port shells out to `docker create`, so embedding those secrets in the container command would expose them through the subprocess argv. It diverged by writing each secret to a temporary host file and copying it with `docker cp`. That worked with ordinary Docker installations, but Docker Snap runs in a separate mount namespace with its own private `/tmp`. The Supabase process could create the file, while the confined Docker client resolving the same path could not see it. new pathless transfer preserves Go’s imp behavior. secrets cross the Docker connection and exist before the service starts, while remaining safe for the ts subprocess arch, remote Docker contexts, and confined container clients... ## ref - Closes #6187
…dates (#6207) Bumps the docker-minor group with 3 updates in the /apps/cli-go/pkg/config/templates directory: supabase/postgres-meta, supabase/realtime and supabase/storage-api. Updates `supabase/postgres-meta` from v0.97.0 to v0.98.0 Updates `supabase/realtime` from v2.124.4 to v2.128.0 Updates `supabase/storage-api` from v1.69.0 to v1.69.9 Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- <details> <summary>Dependabot commands and options</summary> <br /> You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot show <dependency name> ignore conditions` will show all of the ignore conditions of the specified dependency - `@dependabot ignore <dependency name> major version` will close this group update PR and stop Dependabot creating any more for the specific dependency's major version (unless you unignore this specific dependency's major version or upgrade to it yourself) - `@dependabot ignore <dependency name> minor version` will close this group update PR and stop Dependabot creating any more for the specific dependency's minor version (unless you unignore this specific dependency's minor version or upgrade to it yourself) - `@dependabot ignore <dependency name>` will close this group update PR and stop Dependabot creating any more for the specific dependency (unless you unignore this specific dependency or upgrade to it yourself) - `@dependabot unignore <dependency name>` will remove all of the ignore conditions of the specified dependency - `@dependabot unignore <dependency name> <ignore condition>` will remove the ignore condition of the specified dependency and ignore conditions </details> Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
## Summary - Model managed project, checkout, and context identities independently across branch switches, detached `HEAD`, copied branches, and moved worktrees. - Make identity transitions explicit, recoverable, and conflict-safe while preserving fail-closed registry and discovery semantics. - Separate workspace identity policy from stack lifecycle policy behind the managed service composition facade. ## Context Managed stack identity can no longer assume that a checkout path or branch context remains stable after normal Git operations. This change keeps discovery read-only, makes identity publication and recovery atomic, and exposes explicit recovery operations when ownership cannot be proven safely. Metadata pruning remains non-destructive and scoped to records selected by discovery.
## Summary - settle chained managed identity recovery from the latest discovery state - keep branch-scoped transitions isolated while preserving conflict evidence - preserve marker, Git config, and service error semantics across recovery races ## Context This follows PR #6202 and Linear CLI-2108. It addresses confirmed pre-wiring edge cases around interrupted branch recovery, rename-plus-move settlement, folder-to-Git marker reporting, duplicated Git config values, and service shutdown races. Automatic recovery remains internal and bounded. Explicit recovery operations and fail-closed ambiguity behavior are unchanged.
## TL;DR fixes `supabase test db` reporting success on a run that executed zero tests, which was caused by passing `pg_prove`'s exit code straight through when it prints `Result: NOTESTS` and still exits 0 and is now fixed by watching the TAP summary for that verdict and failing with a msg naming the paths that were searched. A typo'd path, an empty tests directory, and a bind mount the Docker daemon resolved against a different filesystem than the CLI all hit this, so CI could stay green while testing nothing. The TAP stream on stdout is unchanged, the diagnostic goes to stderr, and the new exit 1 is recorded in the Go divergence because Go exits 0 here... ## ref: - closes: #6206
## TL;DR In text mode the CLI wrote to stdout with `process.stdout.write` and ignored its return value, so it never waited for a slow reader. Piping a large payload into a slower consumer made Node queue the whole thing in memory, which `supabase db dump` can turn into an OOM on a big database. Writing through the `Stdio` sink is better than hand-checking that return value because the sink already waits for `drain` and handles stream errors, the json and stream-json layers were always doing exactly that, and the old Go CLI had the same behaviour from blocking `os.Stdout` syscall. Text mode was the only outlier, so this removes the inconsistency instead of adding another special case, and all three layers now share one writer. Output bytes and ordering are unchanged.... ## ref: - spotted in: #6210
## Summary - centralize workspace metadata derivation and first-start settlement policy in focused pure modules - remove the obsolete Promise path canonicalizer and share the Git lock retry schedule - strengthen deterministic recovery-race coverage, close a SQLite test handle leak, and correct architecture documentation This is a maintainability follow-up to #6214. It deliberately keeps the broader `packages/stack` decomposition out of scope so that work can be designed separately.
…s/cli-go/pkg/config/templates in the docker-minor group (#6226) Bumps the docker-minor group in /apps/cli-go/pkg/config/templates with 1 update: supabase/realtime. Updates `supabase/realtime` from v2.128.0 to v2.128.2 [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- <details> <summary>Dependabot commands and options</summary> <br /> You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot show <dependency name> ignore conditions` will show all of the ignore conditions of the specified dependency - `@dependabot ignore <dependency name> major version` will close this group update PR and stop Dependabot creating any more for the specific dependency's major version (unless you unignore this specific dependency's major version or upgrade to it yourself) - `@dependabot ignore <dependency name> minor version` will close this group update PR and stop Dependabot creating any more for the specific dependency's minor version (unless you unignore this specific dependency's minor version or upgrade to it yourself) - `@dependabot ignore <dependency name>` will close this group update PR and stop Dependabot creating any more for the specific dependency (unless you unignore this specific dependency or upgrade to it yourself) - `@dependabot unignore <dependency name>` will remove all of the ignore conditions of the specified dependency - `@dependabot unignore <dependency name> <ignore condition>` will remove the ignore condition of the specified dependency and ignore conditions </details> Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
…6102) Bundles `@supabase/pg-delta` and `@supabase/pg-topo` into the CLI and makes the in-process engine the default for pg-delta-backed `db diff`, `db pull`, and the declarative schema workflows (`db schema declarative generate|sync`). The legacy edge-runtime implementation remains available as an explicit `SUPABASE_USE_PG_DELTA_NEXT=false` opt-out; there is no automatic fallback or runtime package download — a next-engine failure propagates instead of silently switching implementations. This branch is reconciled with the TypeScript database-command port on `develop`: - shared database bootstrap owns shadow-database setup and receives the complete local configuration, including database webhooks - pgAdmin uses the native TypeScript differ-container path, while `db diff --use-pg-schema` remains the sole Go delegation - `--project-ref` resolution stays in the TypeScript command path and is rejected for delegated modes that cannot honor it - local diffs target the running local database, while migration and declarative baselines use isolated shadow databases - declarative flows repair missing extension prerequisites, scope schema filters, and warn when unsupported object kinds would be omitted - when a legacy declarative tree cannot converge on the next engine, sync offers a staged recovery flow: it generates a next-compatible export into a sibling `<declarative_schema_path>-next` directory (never inside the active tree — trailing separators in the configured path are normalized, and staging into or under the active directory is rejected) and prints adoption commands built from the configured path - both compatibility gates (shadow-load failure and plan-refuse) render one shared recovery template: diagnosis, evidence, an explicit do-not-apply hazard line, and the staged-upgrade commands carried as the error suggestion — so a deliberate gate prints actionable guidance instead of the generic "rerun with --debug" footer. Non-interactive runs get exactly one recommended recovery (the staged regenerate); interactive prompts keep in-place extension repair as an advanced choice with a "may surface another gap" hint - `db pull` when already in sync keeps Go's "No schema changes found" message and non-zero exit, but replaces the debug footer with an explanatory suggestion (recorded in `go-cli-divergences.md`) - migration files preserve pg-delta's `transaction=false` directive so later push, reset, and up operations keep those plans outside CLI-owned transactions - migrations that call `pg_net` while local webhooks are disabled now surface targeted guidance to enable `[experimental.webhooks]` Default-engine snapshots, plans, and diagnostics use an isolated v2 artifact layout. Extraction errors are refused; coverage gaps warn by default and can be promoted to failures with `--strict-coverage` on `db diff`, `db pull`, and the declarative commands (a TS-only flag, recorded in `docs/go-cli-divergences.md`). Generated SQL and file segmentation may differ from the legacy renderer — the compatibility contract is successful execution and convergence on a subsequent diff. The branch pins published `@supabase/pg-delta@1.0.0-alpha.41` and `@supabase/pg-topo@1.0.0-alpha.5` from the npm registry, and patches the libpg-query parser packaging so the WASM asset is embedded in compiled Bun binaries (with an integration test verifying the patched asset survives compilation). A live local-convergence suite (`legacy-pgdelta-next.live.test.ts`) exercises the next engine against a real Docker stack. It is gated on the configured live environment plus a Docker probe (`describeDockerLive`), so it runs only under the cli-e2e-ci harness — machines that merely expose Docker stay inert. The earlier dogfooding playbook, ADR, and glossary documents were trimmed out of this PR to keep it scoped to the engine change. Linked-project, TLS-required, and pooler/SNI acceptance still needs a provisioned data-plane environment because the shared live harness does not create project Postgres. --------- Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
## TL;DR fixes `supabase db reset` and `db push` taking minutes to run ( on windows ) bringing the port much closer to the Go CLI by batching migration and seed statements the same way it used to ## what was happening? The native TypeScript port ran every SQL statement as its own database round trip The Go CLI it replaced sent a whole file down the wire at once so big dump style migrations that used to apply in seconds started taking minutes. Seed files had the same per statement loop... ## hows it fixed? Go pipelined a whole file over the extended protocol and ended it with a single Sync, and we now follow that exactly, one Parse/Bind/Execute per statement and one Sync per batch. Statements that can't live inside a batch (CREATE INDEX CONCURRENTLY, VACUUM, ALTER SYSTEM, CLUSTER) still run standalone the way they always did since Postgres refuses to run those inside a transaction. The history insert and the seed hash upsert ride in the final batch, so a file is only recorded once everything in it succeeded... ## ref: - closes: #6172 Co-authored-by: avallete <andrew.valleteau@supabase.io>
## TL;DR #6038 sorted migrations by version for `db push` and `migration up` but left three sibling consumers reading the same data in file name order. ## what's broken? - `migration list` renders 2 migrations as 3 rows, one version shown as both remote only and local only - `db pull` flags an in-sync tree as a conflict and asks to repair the same version both reverted and applied - `db reset` / `db start` / the shadow db replay migrations in the reverse of the order `db push` applies ## why was it biting? The database returns migrations sorted by version, the files come back sorted by filename, and the two disagree whenever one version starts another: `20260420010000_b` sorts first by filename, second by version. our earlier fix sorted only the list `db push` reads, so the rest kept comparing the two orders as if they matched... ## fixed now by: One shared version sorter applied at the list merge, the pull reconcile walk, and the two replay owners. |invoked as | before | now | |---|---|---| | `migration list` | 3 rows for 2 migrations | 2 paired rows | | `db pull` | false conflict, contradictory advice | in-sync | | `db reset` / `db diff` replay | reverse of `db push` | same as `db push` | ## ref: - spotted while working on: #6038 --------- Co-authored-by: avallete <andrew.valleteau@supabase.io>
## Summary Replace the managed local-stack coordination design with a smaller architecture centered on one atomic JSON document per stack, deterministic loopback ownership, and one detached supervisor. - derive stack identity from the workspace, checkout, development context, canonical local-project key, and stack name, so multiple Supabase projects inside one monorepo remain isolated - keep automatic ports sticky per stack while respecting configured exact ports and deterministic control endpoints - support detached start, later-process reattachment, stop, deletion, and recovery after interrupted lifecycle operations - keep Docker and native execution behind the same Effect-native `@supabase/stack` package - report running configuration drift without rebinding live services ## Why The previous implementation spread these guarantees across SQLite, repository adapters, claims and publication protocols, transition state machines, operation polling, and a large contract-fixture corpus. Those layers duplicated ownership and recovery responsibilities and made ordinary user journeys difficult to follow. The simplified model gives each invariant one owner: - the stack document owns durable identity, sticky ports, lifecycle, launch metadata, and runtime metadata - the deterministic loopback endpoint owns process exclusivity and reattachment - the manager owns identity resolution, port planning, persistence, and repair - the supervisor owns runtime resources from reservation through shutdown ## Identity and monorepos A stack key combines workspace ID, checkout ID, development-context ID, canonical local-project key, and stack name. The local-project key is the canonical project path relative to its Git worktree, or `.` for an ordinary non-Git folder. It is local identity only: it is not a remote project reference or a config `project_id`. This keeps sibling Supabase projects in one repository independent, keeps the same relative project isolated across worktrees, and preserves identity when a whole worktree moves. Renaming a project directory deliberately creates a new local identity. ## Lifecycle and ports Automatic allocations avoid the deterministic control namespace and remain sticky. Explicit exact ports remain usable, including inside that namespace, unless they collide with a known stack control endpoint or an actual listener. A future identity with no document can theoretically derive an endpoint already used as an exact service port; that low-probability collision fails at control acquisition rather than requiring a global registry or forbidding 22,768 legitimate configured ports. Exact durable reservations and automatic runtime reservations are combined behind one scoped lease while each child lease receives only the fields it owns. This keeps placeholders held until the corresponding service binds without leaking ownership assumptions across allocation strategies. Startup, attachment, early stop, stop-during-start, start-during-stop, owner death, concurrent shutdown, deletion, and stale lifecycle recovery share one bounded ownership protocol. Node and Bun route stop through the same daemon shutdown transaction. Store listing degrades corrupt or unreadable entries independently, and read-only project discovery treats unsupported Git metadata as no managed stacks while mutating operations still fail loudly. Moved checkouts can be repaired through the package API while preserving identity and ports; duplicate checkout adoption remains intentionally unsupported. ## Deliberate boundaries - the managed document format is unreleased, so this change does not add migrations or compatibility shims - loopback control-token authentication is deferred because the current localhost risk is low - a CLI repair command is deferred; the package API remains the source of truth - supervisor test runtimes live only in test helpers and are not accepted by production IPC - ordinary unit and integration suites use isolated temp state and may run concurrently; the one full-stack Functions hot-reload smoke stays in the opt-in live suite - coverage focuses on high-value manager, control, supervisor, storage, and real Git journeys ## Follow-ups - [CLI-2198](https://linear.app/supabase/issue/CLI-2198) — remaining real-Git and project-root contract coverage - [CLI-2199](https://linear.app/supabase/issue/CLI-2199) — control diagnostics and retry-policy cleanup - [CLI-2200](https://linear.app/supabase/issue/CLI-2200) — managed list UX and nested-project deletion coverage - [CLI-2201](https://linear.app/supabase/issue/CLI-2201) — later managed workspace repair workflow - [CLI-2202](https://linear.app/supabase/issue/CLI-2202) — remaining runtime failure-path qualification - [CLI-2203](https://linear.app/supabase/issue/CLI-2203) — copied ordinary-folder identity detection Supersedes #6202, #6214, and #6216
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 64d954da2c
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
Comment on lines
+408
to
+409
| : Effect.promise(() => | ||
| legacyRunUpgradeNotice({ |
There was a problem hiding this comment.
On every successful non-delegated legacy invocation, this wraps legacyRunUpgradeNotice—which performs network I/O, multiple filesystem operations, resource acquisition, and error handling—as a Promise and then discards its defect cause. This creates untyped failure and interruption gaps in new runtime code; model the notifier dependencies and file lifecycle as scoped Effects, retaining a Promise facade only at an outer public boundary.
AGENTS.md reference: AGENTS.md:L64-L68
Useful? React with 👍 / 👎.
Comment on lines
+28
to
+31
| signal: | ||
| init?.signal == null | ||
| ? AbortSignal.timeout(30_000) | ||
| : AbortSignal.any([init.signal, AbortSignal.timeout(30_000)]), |
There was a problem hiding this comment.
For a cold stack that needs more than 30 seconds to start or become ready, this blanket timeout aborts /start and /ready even though the stack readiness contract defaults to 180 seconds and supports infinite waits. It is also combined with the caller signal used by SSE requests, so status and log subscriptions are forcibly disconnected after 30 seconds. Use request-specific deadlines and leave readiness and streaming requests governed by their existing policies and cancellation signals.
Useful? React with 👍 / 👎.
Comment on lines
+160
to
+162
| const host = "127.0.0.1"; | ||
| const url = `http://${host}:${port}`; | ||
| return Effect.succeed({ hostname: host, port, url }); |
There was a problem hiding this comment.
On a shared host or whenever another local process is untrusted, moving the daemon transport to a predictable 127.0.0.1 port exposes every control route without authentication. Any local process can scan this small reserved range, read /status (including the stack's secret key and database URL), consume logs, alter launch metadata, or POST /stop; use an unguessable per-owner capability on every route or retain an access-controlled IPC transport.
Useful? React with 👍 / 👎.
…emplates with 3 updates (#6242) Bumps the docker-minor group in /apps/cli-go/pkg/config/templates with 3 updates: supabase/studio, supabase/realtime and supabase/storage-api. Updates `supabase/studio` from 2026.08.10-sha-5b68af1 to 2026.08.17-sha-0c1da8f Updates `supabase/realtime` from v2.128.2 to v2.129.0 Updates `supabase/storage-api` from v1.69.9 to v1.69.11 Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- <details> <summary>Dependabot commands and options</summary> <br /> You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot show <dependency name> ignore conditions` will show all of the ignore conditions of the specified dependency - `@dependabot ignore <dependency name> major version` will close this group update PR and stop Dependabot creating any more for the specific dependency's major version (unless you unignore this specific dependency's major version or upgrade to it yourself) - `@dependabot ignore <dependency name> minor version` will close this group update PR and stop Dependabot creating any more for the specific dependency's minor version (unless you unignore this specific dependency's minor version or upgrade to it yourself) - `@dependabot ignore <dependency name>` will close this group update PR and stop Dependabot creating any more for the specific dependency (unless you unignore this specific dependency or upgrade to it yourself) - `@dependabot unignore <dependency name>` will remove all of the ignore conditions of the specified dependency - `@dependabot unignore <dependency name> <ignore condition>` will remove the ignore condition of the specified dependency and ignore conditions </details> Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 8d95375984
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
Comment on lines
+529
to
+530
| if (shutdown === "requested") yield* built.daemon.beginShutdown; | ||
| yield* manager.recordLifecycle(ownership, { stackId: started.stack.id, lifecycle: "stopped" }); |
There was a problem hiding this comment.
When the detached supervisor receives SIGINT or SIGTERM, the race produces "shutdown", so this guard skips built.daemon.beginShutdown and immediately persists the stack as stopped. Resource cleanup then occurs only through the outer scope finalizer, after runManaged's failure handler; if cleanup fails—for example because Docker becomes unavailable—the document remains stopped while containers or port leases remain, and the next start will not execute the stale-runtime cleanup reserved for running/starting/failed/deleting documents. Run the shutdown transaction for the signal path and record stopped only after it succeeds.
AGENTS.md reference: AGENTS.md:L66-L66
Useful? React with 👍 / 👎.
Comment on lines
+674
to
+678
| const response = yield* Fiber.join(responseFiber); | ||
| child.unref(); | ||
| detached = true; | ||
| return RemoteStack.layer(response.endpoint).pipe( | ||
| Layer.provide(Layer.succeed(HttpTransportClient, client)), |
There was a problem hiding this comment.
When functions dev races with another process that is still starting the same stack, connectLayer rejects the not-yet-ready owner, after which daemonLayer waits for and attaches to that existing supervisor. This return discards response.attached, so startFullStack reports startedByCommand: true; when functions dev exits, its cleanup calls stack.dispose() and stops a stack started by the other process instead of merely restoring the function configuration. Propagate the attached status so callers can distinguish ownership of the stack lifetime.
Useful? React with 👍 / 👎.
| Effect.map(Option.some), | ||
| Effect.catchTag("StackMetadataNotFoundError", () => Effect.succeed(Option.none())), | ||
| ); | ||
| if (Option.isSome(stackCheck) && stackCheck.value.lifecycle === "running") { |
There was a problem hiding this comment.
If a branch switch runs while the managed stack is in the starting lifecycle, this condition skips the stop-and-restart path even though stopDaemon explicitly supports stopping a starting owner. The linked branch has already been persisted above, so the original supervisor can finish startup using the old branch's configuration and versions while subsequent commands target the new branch. Treat both starting and running as active lifecycles that must be stopped and restarted.
Useful? React with 👍 / 👎.
Comment on lines
+105
to
+107
| const status = yield* manager.probeControl(document.id); | ||
| if (status?.state !== "running" || !status.ready) { | ||
| return yield* Effect.fail(noRunningStack(input)); |
There was a problem hiding this comment.
When supabase status runs concurrently with the initial startup of a managed stack, the owner probe returns state: "starting", but this branch turns that into NoRunningStackError. The status handler then finds the persisted document through resolveStackSummary and reports Local Supabase stack is stopped with running: false, even though the supervisor is actively starting services. Preserve the starting lifecycle so status and automation do not mistake an in-progress launch for a stopped stack.
Useful? React with 👍 / 👎.
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.