supabase

38,871 Commits 1,790 Branches 62 Tags

3 Commits

Include renames

Author	SHA1	Message	Date
claude[bot]Claude Pamela Chia	5bdfb8743c	fix(telemetry): give warehouse_disabled the same schema and table counts as warehouse_enabled (#50643 ) <!-- ccr-slack-attribution --> _Requested by Pam Chia · [Slack thread](https://supabase.slack.com/archives/C076KTY11DF/p1789979663384919?thread_ts=1789953229.116889&cid=C076KTY11DF)_ ## I have read the [CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/CONTRIBUTING.md) file. YES ## What kind of change does this PR introduce? Bug fix (telemetry). ## What is the current behavior? Before: Disabling Warehouse fires `warehouse_disabled` with no properties at all, while enabling it fires `warehouse_enabled` with `schemaTargetCount` and `tableTargetCount`. Disables can be counted, but nothing says how much was being replicated when the user turned it off, so churn cannot be segmented by the size or shape of the setup being torn down. ## What is the new behavior? After: `warehouse_disabled` carries `schemaTargetCount` and `tableTargetCount` with exactly the same meaning they have on `warehouse_enabled`: schemas replicated in full, and tables replicated individually on top of those. A disable of a project replicating one whole schema plus two loose tables now reports one schema target and two table targets, so enable and disable volume line up on the same two properties. ## Additional context How: The counts are read once, when the user confirms the dialog, and held in a ref until the mutation succeeds. The setup mutation's own `onSuccess` invalidates the setup-status and replication-sources queries and awaits those refetches before the caller's callback runs, so anything read inside `onSuccess` already reflects the post-disable state and would report nothing replicated. The event is tracked from that hook-level `onSuccess` rather than a `mutateAsync` callback: the status refetch swaps the Disable card out of the panel, and mutate-level callbacks are skipped once the component has unmounted. The shape is reproduced from the `supabase_warehouse` publication through the same helpers the table picker uses — the publication's tables become a selection, and that selection is mapped back to targets against the project's selectable schemas. Counting distinct schemas and tables off the replicated-table list instead would put a different meaning behind the same property names: a fully covered schema would be counted as its individual tables rather than as one schema target, and the two events would no longer be comparable. Both properties are optional. The replicated-table list is assembled from four queries, and when they have not resolved the properties are omitted rather than sent as `0`, so "unknown" is never recorded as "nothing was replicated". Tests: unit tests for the extracted `buildSchemasWithTables` helper, and a component test that drives the disable dialog against a publication covering one schema in full plus one table from another. 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_0197pGnhiAkhiiYiRxY3qVFY --------- Co-authored-by: Claude <noreply@anthropic.com> Co-authored-by: Pamela Chia <pamelachiamayyee@gmail.com>	2026-09-21 20:58:13 +08:00
Jordi Enric	fa7c223209	fix(studio): use Compute management endpoints FUNC-896 (#50393 ) ## Problem Studio still called the legacy `/workers` Management API routes and used the old `project_worker` response contract, so Compute instances could not be listed or retrieved after the API rename. The production API type check also detected drift in the v1 and platform declarations. ## Fix - Regenerate the v1, v2, and platform API declarations from the deployed schemas. - Update Studio list and detail queries to `/compute`. - Align typed fixtures with the Compute response schemas and `project_compute_instance` resource type. - Update platform response type references to the generated `_Output` schema names. ## How to test - Run `pnpm api:verify-types`. - Run `pnpm --filter api-types test`. - Run `pnpm --filter studio test data/compute/compute.utils.test.ts "tests/pages/project/[ref]/compute/index.test.tsx"`. - Run `pnpm --filter studio typecheck`. - Run `pnpm --filter common typecheck`. - Run `pnpm --filter studio lint:ratchet`. Expected result: production API declarations are synchronized, and Studio requests the `/compute` list and detail endpoints and renders `project_compute_instance` responses successfully. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * Improvements * Updated API response handling across profiles, backups, notifications, integrations, warehouses, access tokens, payments, and other Studio workflows for more accurate serialized data. * Compute instance pages and queries now use the compute-specific API endpoints and response data. * Improved feature-flag type handling when disabled feature data is unavailable. * Tests * Updated automated coverage and fixtures to reflect current compute and API response formats. <!-- end of auto-generated comment: release notes by coderabbit.ai -->	2026-09-15 12:50:56 +02:00
Danny WhiteandJoshen Lim	1755580dcf	feat(studio): move Warehouse setup into Integrations (#50247 ) ## What kind of change does this PR introduce? Feature and information architecture change. Builds on #50246. ## What is the current behaviour? Warehouse setup, progress, errors, table selection, and connection details all live in the transient Connect sheet. Closing the sheet hides the current replication state, and the integration is absent from the Integrations page. ## What is the new behaviour? Warehouse now has a persistent Overview page at `/project/{ref}/integrations/warehouse/overview`: - Before setup, the existing schema and table picker enables Warehouse. - During setup, the page shows the current phase and per-table backfill state where available. - Setup and status failures remain visible on the page with retry actions where possible. - Once complete, the page shows Status, Tables, then Connect. - The Connect sheet becomes read-only. Before Warehouse is ready, it links directly to the Overview page for setup, progress, or recovery. \| Before \| After \| \| --- \| --- \| \| <img width="1200" height="907" alt="Chives Pantry Supabase" src="https://github.com/user-attachments/assets/82dc7fb0-3859-499e-96ab-56f70a5c7325" /> \| <img width="1200" height="907" alt="Chives Pantry Supabase" src="https://github.com/user-attachments/assets/7428e301-27f8-48fe-91e0-6880b132920d" /> \| \| <img width="1200" height="907" alt="Chives Pantry Supabase" src="https://github.com/user-attachments/assets/82dc7fb0-3859-499e-96ab-56f70a5c7325" /> \| <img width="1200" height="907" alt="54709" src="https://github.com/user-attachments/assets/0c589e5b-e13c-4554-a6ee-6730d0e95c07" /> \| \| <img width="1200" height="907" alt="ETL BigTable ETL Team Supabase" src="https://github.com/user-attachments/assets/18ec9f6c-3724-453f-bbbb-c7149758246e" /> \| <img width="1200" height="907" alt="Regular AWS Teamer Supabase" src="https://github.com/user-attachments/assets/3819c9fe-e56d-4cec-988d-5e724f8d990a" /> \| ## To test Use a project whose organisation is included in the Warehouse allow-list. 1. Open `/project/{ref}/integrations`, filter by Data platform, and open Warehouse. 2. Before setup, confirm the existing schema and table picker appears and starts with no tables selected. 3. Start setup and confirm the Status section polls through setup and table backfill phases. 4. Confirm setup failures remain visible and expose Retry when the API returns affected tables. 5. After setup, confirm the section order is Status, Tables, Connect. 6. Confirm existing replicated tables are selected and locked, while additional tables can be added. 7. Open `/project/{ref}?showConnect=true&connectTab=warehouse` and confirm it links to the Overview page before setup, during setup, and after a setup failure. 8. Once setup is complete, confirm the Connect sheet shows the FlightSQL and DuckDB connection controls from #50246. 9. Repeat the Overview checks with One-Click Integrations turned off. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * New Features * Added Supabase Warehouse to the integrations catalog, with overview documentation and availability-aware display. * Added Warehouse setup and management flows, including schema and table selection, replication progress, status details, connection options, and retry actions. * Added DuckDB and FlightSQL engine selection with Connect sheet URL and preference synchronization. * Added table replication status, lag, timestamps, and size information. * Bug Fixes * Warehouse setup status requests no longer retry automatically after failures. * Improved recovery messaging and retry behavior for setup and connection errors. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Joshen Lim <joshenlimek@gmail.com>	2026-09-15 12:38:13 +10:00

Author

SHA1

Message

Date

5bdfb8743c

fix(telemetry): give warehouse_disabled the same schema and table counts as warehouse_enabled (#50643 )

<!-- ccr-slack-attribution -->
_Requested by **Pam Chia** · [Slack
thread](https://supabase.slack.com/archives/C076KTY11DF/p1789979663384919?thread_ts=1789953229.116889&cid=C076KTY11DF)_

## I have read the
[CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/CONTRIBUTING.md)
file.

YES

## What kind of change does this PR introduce?

Bug fix (telemetry).

## What is the current behavior?

**Before:** Disabling Warehouse fires `warehouse_disabled` with no
properties at all, while enabling it fires `warehouse_enabled` with
`schemaTargetCount` and `tableTargetCount`. Disables can be counted, but
nothing says how much was being replicated when the user turned it off,
so churn cannot be segmented by the size or shape of the setup being
torn down.

## What is the new behavior?

**After:** `warehouse_disabled` carries `schemaTargetCount` and
`tableTargetCount` with exactly the same meaning they have on
`warehouse_enabled`: schemas replicated in full, and tables replicated
individually on top of those. A disable of a project replicating one
whole schema plus two loose tables now reports one schema target and two
table targets, so enable and disable volume line up on the same two
properties.

## Additional context

**How:** The counts are read once, when the user confirms the dialog,
and held in a ref until the mutation succeeds. The setup mutation's own
`onSuccess` invalidates the setup-status and replication-sources queries
and awaits those refetches before the caller's callback runs, so
anything read inside `onSuccess` already reflects the post-disable state
and would report nothing replicated. The event is tracked from that
hook-level `onSuccess` rather than a `mutateAsync` callback: the status
refetch swaps the Disable card out of the panel, and mutate-level
callbacks are skipped once the component has unmounted.

The shape is reproduced from the `supabase_warehouse` publication
through the same helpers the table picker uses — the publication's
tables become a selection, and that selection is mapped back to targets
against the project's selectable schemas. Counting distinct schemas and
tables off the replicated-table list instead would put a different
meaning behind the same property names: a fully covered schema would be
counted as its individual tables rather than as one schema target, and
the two events would no longer be comparable.

Both properties are optional. The replicated-table list is assembled
from four queries, and when they have not resolved the properties are
omitted rather than sent as `0`, so "unknown" is never recorded as
"nothing was replicated".

Tests: unit tests for the extracted `buildSchemasWithTables` helper, and
a component test that drives the disable dialog against a publication
covering one schema in full plus one table from another.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

https://claude.ai/code/session_0197pGnhiAkhiiYiRxY3qVFY

---------

Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: Pamela Chia <pamelachiamayyee@gmail.com>

2026-09-21 20:58:13 +08:00

Jordi Enric

fa7c223209

fix(studio): use Compute management endpoints FUNC-896 (#50393 )

## Problem

Studio still called the legacy `/workers` Management API routes and used
the old `project_worker` response contract, so Compute instances could
not be listed or retrieved after the API rename. The production API type
check also detected drift in the v1 and platform declarations.

## Fix

- Regenerate the v1, v2, and platform API declarations from the deployed
schemas.
- Update Studio list and detail queries to `/compute`.
- Align typed fixtures with the Compute response schemas and
`project_compute_instance` resource type.
- Update platform response type references to the generated `_Output`
schema names.

## How to test

- Run `pnpm api:verify-types`.
- Run `pnpm --filter api-types test`.
- Run `pnpm --filter studio test data/compute/compute.utils.test.ts
"tests/pages/project/[ref]/compute/index.test.tsx"`.
- Run `pnpm --filter studio typecheck`.
- Run `pnpm --filter common typecheck`.
- Run `pnpm --filter studio lint:ratchet`.

Expected result: production API declarations are synchronized, and
Studio requests the `/compute` list and detail endpoints and renders
`project_compute_instance` responses successfully.

<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->

## Summary by CodeRabbit

* **Improvements**
* Updated API response handling across profiles, backups, notifications,
integrations, warehouses, access tokens, payments, and other Studio
workflows for more accurate serialized data.
* Compute instance pages and queries now use the compute-specific API
endpoints and response data.
* Improved feature-flag type handling when disabled feature data is
unavailable.

* **Tests**
* Updated automated coverage and fixtures to reflect current compute and
API response formats.

<!-- end of auto-generated comment: release notes by coderabbit.ai -->

2026-09-15 12:50:56 +02:00

Danny WhiteandJoshen Lim

1755580dcf

feat(studio): move Warehouse setup into Integrations (#50247 )

## What kind of change does this PR introduce?

Feature and information architecture change. Builds on #50246.

## What is the current behaviour?

Warehouse setup, progress, errors, table selection, and connection
details all live in the transient Connect sheet. Closing the sheet hides
the current replication state, and the integration is absent from the
Integrations page.

## What is the new behaviour?

Warehouse now has a persistent Overview page at
`/project/{ref}/integrations/warehouse/overview`:

- Before setup, the existing schema and table picker enables Warehouse.
- During setup, the page shows the current phase and per-table backfill
state where available.
- Setup and status failures remain visible on the page with retry
actions where possible.
- Once complete, the page shows Status, Tables, then Connect.
- The Connect sheet becomes read-only. Before Warehouse is ready, it
links directly to the Overview page for setup, progress, or recovery.

| Before | After |
| --- | --- |
| <img width="1200" height="907" alt="Chives Pantry Supabase"
src="https://github.com/user-attachments/assets/82dc7fb0-3859-499e-96ab-56f70a5c7325"
/> | <img width="1200" height="907" alt="Chives Pantry Supabase"
src="https://github.com/user-attachments/assets/7428e301-27f8-48fe-91e0-6880b132920d"
/> |
| <img width="1200" height="907" alt="Chives Pantry Supabase"
src="https://github.com/user-attachments/assets/82dc7fb0-3859-499e-96ab-56f70a5c7325"
/> | <img width="1200" height="907" alt="54709"
src="https://github.com/user-attachments/assets/0c589e5b-e13c-4554-a6ee-6730d0e95c07"
/> |
| <img width="1200" height="907" alt="ETL BigTable ETL Team Supabase"
src="https://github.com/user-attachments/assets/18ec9f6c-3724-453f-bbbb-c7149758246e"
/> | <img width="1200" height="907" alt="Regular AWS Teamer Supabase"
src="https://github.com/user-attachments/assets/3819c9fe-e56d-4cec-988d-5e724f8d990a"
/> |

## To test

Use a project whose organisation is included in the Warehouse
allow-list.

1. Open `/project/{ref}/integrations`, filter by **Data platform**, and
open Warehouse.
2. Before setup, confirm the existing schema and table picker appears
and starts with no tables selected.
3. Start setup and confirm the Status section polls through setup and
table backfill phases.
4. Confirm setup failures remain visible and expose Retry when the API
returns affected tables.
5. After setup, confirm the section order is Status, Tables, Connect.
6. Confirm existing replicated tables are selected and locked, while
additional tables can be added.
7. Open `/project/{ref}?showConnect=true&connectTab=warehouse` and
confirm it links to the Overview page before setup, during setup, and
after a setup failure.
8. Once setup is complete, confirm the Connect sheet shows the FlightSQL
and DuckDB connection controls from #50246.
9. Repeat the Overview checks with **One-Click Integrations** turned
off.


<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit

* **New Features**
* Added Supabase Warehouse to the integrations catalog, with overview
documentation and availability-aware display.
* Added Warehouse setup and management flows, including schema and table
selection, replication progress, status details, connection options, and
retry actions.
* Added DuckDB and FlightSQL engine selection with Connect sheet URL and
preference synchronization.
* Added table replication status, lag, timestamps, and size information.

* **Bug Fixes**
* Warehouse setup status requests no longer retry automatically after
failures.
* Improved recovery messaging and retry behavior for setup and
connection errors.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->

---------

Co-authored-by: Joshen Lim <joshenlimek@gmail.com>

2026-09-15 12:38:13 +10:00