| Files | Last commit | Last update |
|---|---|---|
feat(cli): add inspect db toast-sizes command (#6528) ## Summary Adds `supabase inspect db toast-sizes` — a new `inspect db` subcommand that lists user tables with TOAST storage, ordered by TOAST size (largest first). ## What changed - `apps/cli/src/commands/inspect/db/toast-sizes/` — 3-file subcommand (query, handler, command) - `apps/cli/docs/supabase/inspect/db-toast-sizes.md` — docs overlay with description and sample output - `apps/cli/src/commands/inspect/db/db.command.ts` — registers the new subcommand - `apps/cli/src/commands/inspect/db/SIDE_EFFECTS.md` — updates active count (13 → 14) and query table - `apps/cli/src/commands/inspect/db/inspect-specs.integration.test.ts` — adds a test case for `toastSizesSpec` ## Why it matters TOAST (The Oversized-Attribute Storage Technique) is PostgreSQL's overflow storage for large values in `TEXT`, `JSONB`, and `bytea` columns. Autovacuum runs on TOAST tables **independently** from the main heap, so dead TOAST chunks accumulate silently. A high TOAST dead-tuple ratio increases I/O and inflates effective database size — but it doesn't appear in the existing `bloat` or `vacuum-stats` commands, which only cover the main heap. This command surfaces: - Heap vs. TOAST size split per table - Live/dead TOAST chunk counts and dead-chunk percentage - Last autovacuum/vacuum timestamps on the TOAST table It's a common source of invisible bloat, especially in tables with large JSONB columns. ## Testing - New integration test case in `inspect-specs.integration.test.ts` (count updated 13 → 14) - Query filters out internal Supabase schemas via the shared `$1` LIKE-escape parameter (consistent with `bloat`, `vacuum-stats`, `index-stats`, `table-stats`, `db-stats`) - Docs overlay at `apps/cli/docs/supabase/inspect/db-toast-sizes.md` follows the same format as existing overlays ## Docs A follow-up PR to `supabase/supabase` will add this command to the [Inspect guide](https://supabase.com/docs/guides/observability/inspect) under the **Disk Storage Analysis** section after this merges. --------- Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com> Co-authored-by: avallete <andrew.valleteau@supabase.io> | 3 days ago | |
test(cli-e2e): cover the replay server with effect lint (CLI-2880) (#7387) ## TL;DR brings the `apps/cli-e2e` replay server under the effect lint, so the allow list covers the whole ## whats introduced? - the server runs on `FileSystem`, `HttpClient` and typed errors with `Bun.serve` as its only edge, and the global setup owns it through a scope - the docker relay uses the `node:http` client from `@effect/platform-node`, because bun's `fetch` sorts response headers and recorded fixtures keep them in arrival order - replay responses and recorded fixture files stay byte for byte the same ps: in record mode the docker relay can send a response chunked where it used to send `content-length`, with the same body bytes, and a failed relay logs its own error instead of the raw socket error ## ref - closes: CLI-2880 | 7 days ago | |
feat(cli): add inspect db toast-sizes command (#6528) ## Summary Adds `supabase inspect db toast-sizes` — a new `inspect db` subcommand that lists user tables with TOAST storage, ordered by TOAST size (largest first). ## What changed - `apps/cli/src/commands/inspect/db/toast-sizes/` — 3-file subcommand (query, handler, command) - `apps/cli/docs/supabase/inspect/db-toast-sizes.md` — docs overlay with description and sample output - `apps/cli/src/commands/inspect/db/db.command.ts` — registers the new subcommand - `apps/cli/src/commands/inspect/db/SIDE_EFFECTS.md` — updates active count (13 → 14) and query table - `apps/cli/src/commands/inspect/db/inspect-specs.integration.test.ts` — adds a test case for `toastSizesSpec` ## Why it matters TOAST (The Oversized-Attribute Storage Technique) is PostgreSQL's overflow storage for large values in `TEXT`, `JSONB`, and `bytea` columns. Autovacuum runs on TOAST tables **independently** from the main heap, so dead TOAST chunks accumulate silently. A high TOAST dead-tuple ratio increases I/O and inflates effective database size — but it doesn't appear in the existing `bloat` or `vacuum-stats` commands, which only cover the main heap. This command surfaces: - Heap vs. TOAST size split per table - Live/dead TOAST chunk counts and dead-chunk percentage - Last autovacuum/vacuum timestamps on the TOAST table It's a common source of invisible bloat, especially in tables with large JSONB columns. ## Testing - New integration test case in `inspect-specs.integration.test.ts` (count updated 13 → 14) - Query filters out internal Supabase schemas via the shared `$1` LIKE-escape parameter (consistent with `bloat`, `vacuum-stats`, `index-stats`, `table-stats`, `db-stats`) - Docs overlay at `apps/cli/docs/supabase/inspect/db-toast-sizes.md` follows the same format as existing overlays ## Docs A follow-up PR to `supabase/supabase` will add this command to the [Inspect guide](https://supabase.com/docs/guides/observability/inspect) under the **Disk Storage Analysis** section after this merges. --------- Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com> Co-authored-by: avallete <andrew.valleteau@supabase.io> | 3 days ago | |
test(cli-e2e): cover the replay server with effect lint (CLI-2880) (#7387) ## TL;DR brings the `apps/cli-e2e` replay server under the effect lint, so the allow list covers the whole ## whats introduced? - the server runs on `FileSystem`, `HttpClient` and typed errors with `Bun.serve` as its only edge, and the global setup owns it through a scope - the docker relay uses the `node:http` client from `@effect/platform-node`, because bun's `fetch` sorts response headers and recorded fixtures keep them in arrival order - replay responses and recorded fixture files stay byte for byte the same ps: in record mode the docker relay can send a response chunked where it used to send `content-length`, with the same body bytes, and a failed relay logs its own error instead of the raw socket error ## ref - closes: CLI-2880 | 7 days ago | |
feat(cli)!: remove deprecated commands and the supabase-go binary (#6609) Removes the last of the Go CLI: the deprecated commands and flags the TypeScript CLI still forwarded to a bundled `supabase-go` binary, and the Go source tree, toolchain and packaging behind them. Targets `next`, so it ships in the next major. The user-facing changes are in the `BREAKING CHANGE` footer at the end, which is what the release notes pick up. ## Notes for reviewers - The removed commands and flags stay registered but hidden, so using one exits 1 with its replacement rather than an unknown-command error. Each records a `RemovedSurfaceError` telemetry fingerprint (`removed_command` / `removed_flag`), so remaining usage can be tracked before the stubs are deleted outright. - `GoProxy` and its wiring in `cli/root.ts` and `shared/cli/run.ts` are deleted. - `apps/cli-go/` is deleted (its `LICENSE` moves to the repo root), along with the Go CI workflows, toolchain entries and Go-specific lint, format, knip, CODEOWNERS and dependabot config. Every platform package ships one `supabase` binary, and the install script removes a leftover `supabase-go`. - The `pkg/v*` tags of `github.com/supabase/cli/pkg` are frozen and protected by a ruleset. [ADR 0030](docs/adr/0030-go-cli-removal.md) records the removal, supersedes ADR 0016, and lists the known external importers of that module. Part of CLI-2432 BREAKING CHANGE: Removed the deprecated commands and flags that still ran through the bundled Go binary, and the `supabase-go` binary itself. If your scripts or CI use any of these, switch to the replacement. Each removed command or flag now exits with code 1 and prints its replacement. - `supabase db remote changes` → `supabase db diff --linked` - `supabase gen keys` → `supabase projects api-keys --project-ref <ref>` - `supabase db diff --use-pg-schema` → omit the flag to use the default engine, or pass `--use-pg-delta` - `supabase functions download --legacy-bundle` → `supabase functions download --use-api`. If that also fails and the Function was deployed with a CLI older than 1.120.0, redeploy it with the current CLI first. - `supabase db branch create`, `delete`, `list` and `switch` → removed with no local replacement. Hosted preview branches are managed with `supabase branches`. - `--create-ticket` (global flag) → removed. Report CLI problems with `supabase issue bug`. - `supabase-go` → no longer installed. Call `supabase` instead. --------- Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com> | 29 days ago | |
chore(repo): fold the effect lint into the repo lint (CLI-2899) (#7422) ## TL;DR folds the effect lint into `pnpm lint:check`, so one `.oxlintrc.json` drives editors, agents and CI ## whats introduced? - `.oxlintrc.json` extends the `@effect/tsgo` recommended preset, and `.oxlintrc.effect.json` and the `lint:effect:*` scripts go away - `.github/scripts`, the npm launcher shim, compute stack templates and the generated API contracts move to `ignorePatterns`, so they leave the repo lint entirely - `lint:fix` applies suggestions, and `fix:all` runs knip, lint and format in order so fixes never race ## ref - closes: CLI-2899 & CLI-2407 | 4 days ago | |
test(cli-e2e): cover the replay server with effect lint (CLI-2880) (#7387) ## TL;DR brings the `apps/cli-e2e` replay server under the effect lint, so the allow list covers the whole ## whats introduced? - the server runs on `FileSystem`, `HttpClient` and typed errors with `Bun.serve` as its only edge, and the global setup owns it through a scope - the docker relay uses the `node:http` client from `@effect/platform-node`, because bun's `fetch` sorts response headers and recorded fixtures keep them in arrival order - replay responses and recorded fixture files stay byte for byte the same ps: in record mode the docker relay can send a response chunked where it used to send `content-length`, with the same body bytes, and a failed relay logs its own error instead of the raw socket error ## ref - closes: CLI-2880 | 7 days ago | |
test(cli-e2e): add live e2e suite covering the CLI command matrix (#5588) ## What Adds a **live** e2e mode to `apps/cli-e2e` and a real-staging command matrix on top of it, per [CLI-1630](https://linear.app/supabase/issue/CLI-1630/set-up-proper-live-e2e-tests-for-the-cli) and [ADR-0013](https://github.com/supabase/cli/blob/develop/docs/adr/0013-live-e2e-bypasses-replay-server.md). Live mode is a third mode (`CLI_E2E_MODE=live`) that, unlike replay/record, **does not use the replay server**. The harness points the CLI straight at the real Management API (`CLI_E2E_API_URL`) and the real Docker socket; tests assert on **real outcomes** — process exit codes, the HTTP responses of deployed functions (status + JSON body), and real DB/Storage state. This is ID-agnostic, so there are no snapshots/normalization by default. ## Changes - **`env.ts`** — `CLI_E2E_MODE` (`replay`/`record`/`live`), `isLive`, `TARGET_API_URL`, `CLI_E2E_PROJECT_HOST`; back-compat `RECORD=true` → `record`. - **`tests/staging-project.ts`** — project-lifecycle helpers extracted from `setup.ts`: create/delete an ephemeral project, resolve the anon JWT, the IPv4 **session-pooler `dbUrl`**, the service-role key, and seed a Storage bucket. Record behavior is unchanged. - **`tests/live-setup.ts`** — global setup that provisions **one ephemeral project per run** (`cli-e2e-live-{target}-{runId}-{short}`), waits `ACTIVE_HEALTHY`, and exposes `projectRef`/`anonKey`/`functionsUrl`/`dbUrl`/`storageBucket` via `inject()`; deletes the project on teardown (even on failure). Intentionally dumb — no in-setup retry. - **`src/tests/live/`** — `testLive` context (direct-wired `run`, HTTP `invoke` sending the anon JWT, a `supabase init`-generated `workspace`, `seedFunctions` to layer the `deploy-e2e-*` fixtures + their `[functions.*]` config) plus live coverage for: functions deploy (the three bundler modes + deploy-all), functions lifecycle (re-deploy + delete), database (`inspect`/`migration list`/`db dump`), db push→pull, `link`, `projects`, `gen types`, `branches`, `storage`, `secrets`. - **`vitest.live.config.ts`** + `test:e2e:live`; the default config excludes `*.live.e2e.test.ts`. - **`harness.ts`** — `projectHost` option so host-derived commands (`storage --linked` → `<ref>.<host>`, `db.<ref>.<host>`) reach the real endpoint instead of `localhost`. - **`.github/workflows/live-e2e.yml`** — `workflow_dispatch` + an hourly `@beta` `schedule`; `go` + `ts-legacy` matrix (`fail-fast: false`); `docker info` preflight; 3× retry; project cleanup scoped to the job's own prefix. - **`apps/cli/.../functions/deploy/deploy.e2e.test.ts`** — collocated integration coverage for the negative/arg-validation cases that don't belong in the live suite. - **`docs/adr/0013-…`** + README index row; `fixtures/live/functions-project/` `deploy-e2e-*` functions. ## Reviewer notes - **Why bypass the replay server.** Live mode is a deliberately different signal from the replay suite: it exercises the real subprocess, real runtime wiring, and real cross-boundary behavior (API + Docker + DB + Storage) that fixtures can't represent. The replay suite stays the fast, deterministic default. - **IPv6 → IPv4 pooler.** Staging's direct DB host (`db.<ref>.supabase.red`) is **IPv6-only by design**, and the CI runners have **no IPv6 egress** — so DB-touching commands connect through the project's **IPv4 session-mode Supavisor pooler** via `--db-url` (the CLI's own blessed fallback). Session mode (not transaction `6543`) is required for `pg_dump`. - **Authoring target is `go`** (source of truth for the port); `ts-legacy` runs the same tests to prove the shim matches. Both run as separate CI jobs (independent green/red signals). - **Trigger model.** There is **no `pull_request` trigger** — run the workflow manually on a branch for pre-merge coverage. `workflow_dispatch` (Actions branch picker; no free-form `ref` input, so the staging token never reaches arbitrary code) and `schedule` only become active once this file is on the default branch (`develop`) — classic GitHub bootstrap. The hourly run exercises the `@beta` channel: `develop` is the default branch and the beta release source, so it builds `develop` from source and runs the same matrix. A `gate` job skips the run unless the published `supabase@beta` version changed since the last green run (an `actions/cache` marker keyed on the version, written by `finalize` only after **both** legs pass). - **Secret / fork safety.** Uses `SUPABASE_E2E_CLI_LIVE_STAGING_ACCESS_TOKEN`; never `pull_request_target`, so the token is never exposed to fork code. - **Out of scope:** `config push` surfaced a TS↔remote config-schema parity bug on `ts-legacy`, tracked separately in [CLI-1810](https://linear.app/supabase/issue/CLI-1810/config-push-fails-on-ts-legacy-ts-config-schema-rejects-remote-storage); it is intentionally not covered here. Refs: CLI-1630 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com> | 4 months ago | |
test(cli-e2e): cover the e2e harness with effect lint (CLI-2878) (#7384) ## TL;DR brings the `apps/cli-e2e` harness under the effect lint ## whats introduced? - `env.ts` reads the environment through `Config` and passes the record mode and staging url to the global setup instead of rewriting `process.env` - the global setup, staging project helpers, fixture loader, pg mock and vitest config run as effect programs - the fixture loader decodes fixtures through a schema, so a hand written fixture missing a field fails at load with its file name, and every committed fixture decodes unchanged - the replay server stays excluded until the last page of this stack ## ref - related: CLI-2878 | 7 days ago |
| Files | Last commit | Last update |
|---|---|---|
| 3 days ago | ||
| 7 days ago | ||
| 3 days ago | ||
| 7 days ago | ||
| 29 days ago | ||
| 4 days ago | ||
| 7 days ago | ||
| 4 months ago | ||
| 7 days ago |