Commit Graph
5 Commits
Author SHA1 Message Date
Danny White a4be167491 fix(studio): clarify Warehouse status and navigation (#50554)
## What kind of change does this PR introduce?

Bug fix and UI polish.

## What is the current behavior?

The Warehouse Connect option repeats its own name, and a configured
Warehouse has no direct route back to its management page. Warehouse
table states also use badges instead of the status-dot pattern used by
Replication, and a backfilling table can misleadingly appear as “Caught
up”.

## What is the new behavior?

- Describes Warehouse as an analytical endpoint and adds a low-emphasis
“Manage Warehouse” link from the Connect sheet.
- Shares Replication’s status-dot presentation with Warehouse while
keeping feature-specific state mapping separate.
- Shows replication lag only for live tables, so backfilling and “Caught
up” are never presented together.

| Before | After |
| --- | --- |
| <img width="1244" height="1156" alt="CleanShot 2026-09-18 at 14 03
49@2x"
src="https://github.com/user-attachments/assets/60aa3496-6930-491a-af9e-9ffcfb035a0f"
/> | <img width="1216" height="1214" alt="CleanShot 2026-09-18 at 14 04
33@2x"
src="https://github.com/user-attachments/assets/84a8c80e-d8d1-4ee5-9cce-352d1f6477c2"
/> |
| <img width="1314" height="1414" alt="CleanShot 2026-09-18 at 14 02
50@2x"
src="https://github.com/user-attachments/assets/8871a4a5-0543-4290-91a7-9da949ec4c49"
/> | <img width="1308" height="1498" alt="CleanShot 2026-09-18 at 14 02
43@2x"
src="https://github.com/user-attachments/assets/ac3fc6d1-5b4d-4a3a-8ab7-bb54025e2145"
/> |

## To test

1. Open `/project/<ref>?showConnect=true&connectTab=warehouse` for a
project with Warehouse configured. Confirm the mode subtitle says
“Analytical endpoint”. Confirm the new “Manage Warehouse” button opens
`/project/<ref>/integrations/warehouse/overview`.
2. Open `/project/<ref>/integrations/warehouse/overview` while a table
is backfilling. Confirm it has a pulsing amber status dot and does not
show “Caught up”.
3. Once the table is live, confirm it has a green “Live” status dot and
its lag appears normally.

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

- **New Features**
- Added clearer Warehouse setup progress messaging with a “View
progress” action while setup is running.
- Connection details are shown once the Warehouse is provisioned or has
live tables.
- Added a Cancel action when editing changed Warehouse table selections.
- Updated table statuses with live, syncing, and warning indicators,
including animated syncing states.
  - Lag details are displayed for live tables when available.
  - Renamed the Warehouse connection option to “Analytical endpoint.”

- **Style**
  - Improved Warehouse management controls and table name readability.
  - Removed the table Size column from the Warehouse overview.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
2026-09-22 12:21:40 +10:00
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
Danny White 3e2d54eccb feat(studio): add Warehouse table management and disable (#50195)
## What kind of change does this PR introduce?

Feature and UI polish.

## What is the current behavior?

Warehouse setup uses a schema accordion for table selection. Once
Warehouse is enabled, users cannot remove replicated tables or disable
Warehouse from Studio.

## What is the new behavior?

- Replaces the schema accordion with one grouped, searchable table
selector.
- Still allows for **Select all** and **Clear** actions for each schema.
- Starts first-time setup with no tables selected and preselects current
replicated tables when editing.
	- Adds support for removing previously replicated tables.
- Adds a confirmed **Disable Warehouse** action.
- Tracks successful Warehouse enable and disable actions.

Disabling Warehouse removes its replication pipeline, publication,
catalogue access, and foreign tables. Copied data remains in DuckLake
storage until the user deletes it. Re-enabling a table rebuilds its data
rather than reusing the retained copy.

| Before | After |
| --- | --- |
| <img width="1024" height="759" alt="Integrations Test US East 1 testdw
Supabase"
src="https://github.com/user-attachments/assets/bded025b-1d45-41dc-8a35-9159baf8f9b7"
/> | <img width="1024" height="759" alt="Integrations test Teamer
Supabase"
src="https://github.com/user-attachments/assets/69026d94-98a0-4878-ab58-2e9697296d93"
/> |
| <img width="1280" height="1323" alt="Integrations Test testdw
Supabase"
src="https://github.com/user-attachments/assets/3f71e754-1a87-4d58-a7b9-dd39d3e0ac5a"
/> | <img width="1280" height="1323" alt="Integrations Regular AWS
Teamer Supabase"
src="https://github.com/user-attachments/assets/758ed48e-9ed6-45d3-ae94-e171147a21d5"
/> |
| _Feature did not exist_ | <img width="1024" height="759"
alt="Integrations Regular AWS Teamer Supabase"
src="https://github.com/user-attachments/assets/c977ac57-8b0c-4482-882b-69ad7602b5df"
/> |

## Additional context

Platform support for updating and disabling Warehouse was added in
[supabase/platform#38190](https://github.com/supabase/platform/pull/38190).

### To test

1. Open `/project/{ref}/integrations/warehouse/overview` before setup.
2. Confirm **Tables to replicate** starts at zero and **Enable
Warehouse** is disabled until a table is selected.
3. Confirm each schema's **Select all** and **Clear** actions update
every table in that schema.
4. Enable Warehouse with a partial selection and wait for setup to
complete.
5. Edit the selection, add and remove replicated tables, then confirm
the saved selection is reflected in the publication.
6. Disable Warehouse, confirm the retention warning, and verify the
integration returns to its initial state.
7. Re-enable Warehouse and confirm selected tables are rebuilt.
8. Trigger a replication pipeline limit error and confirm the inline
guidance links to Database Replication.

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

- **New Features**
  - Added the ability to disable Warehouse from the setup panel.
  - Warehouse setup now starts with no table selections.
- Editing a setup preselects replicated tables and supports updating
selections, including removing tables.
- Added searchable schema and table selection with screen-reader count
announcements.
  - Added telemetry tracking for initial Warehouse enablement.

- **Bug Fixes**
- Warehouse disable failures now show an error while keeping the
confirmation dialog open for retry.
  - Configuration updates now refresh related data automatically.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
2026-09-17 14:17:00 +10: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