mirror of
https://github.com/supabase/supabase.git
synced 2026-10-05 17:35:10 +03:00
codex/fix-tanstack-e2e
1346
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
|
|
544f4e7195 |
chore(studio): pass integration listing by slug when installing (#46119)
Passes listings by slug instead of UUID when getting an installation URL. This is already supported in the Platform API in a backwards compatible way. Toward INT-109 |
||
|
|
08c0fc247b |
feat(studio): warn about pg_graphql introspection change on upgrade (#46096)
<img width="1512" height="818" alt="introspection" src="https://github.com/user-attachments/assets/5c0e4c6a-c0e9-496d-8768-4a55a2433268" /> ## Summary Adds an in-product admonition on the Infrastructure Settings page when a project has pg_graphql < 1.6.0 installed, warning users that GraphQL introspection will be disabled by default after upgrading. Links to upgrade notes docs with the opt-in SQL. The admonition is purely informational — it renders alongside the upgrade button, does not block the upgrade. ## Context pg_graphql 1.6.0 disables GraphQL introspection by default. The change is upgrade-triggered (not backported), so users on 1.5.x will only encounter it when their AMI bundles 1.6.0+. To prevent surprise breakage of tools that rely on `__schema`/`__type` (GraphiQL, codegen, Relay compiler, etc.), Studio surfaces this admonition before they upgrade. Design discussion in [PSQL-1199](https://linear.app/supabase/issue/PSQL-1199/prepare-dashboard-notification-for-pg-graphql-breaking-change). ## Companion PR This depends on the schema change in [supabase/platform#32954](https://github.com/supabase/platform/pull/32954) which adds the new `warnings` field to `ProjectUpgradeEligibilityResponse`. ## Admonition copy - **Title:** \"GraphQL introspection will be disabled by default after upgrade\" - **Body:** \"After upgrading, queries to \`__schema\` and \`__type\` will return an error unless introspection is explicitly re-enabled on the schema. Regular data queries are not affected.\" - **CTA:** \"Read upgrade notes\" → links to the new docs section ## Related - Linear: [PSQL-1199](https://linear.app/supabase/issue/PSQL-1199/prepare-dashboard-notification-for-pg-graphql-breaking-change) - Parent rollout: [PSQL-1163](https://linear.app/supabase/issue/PSQL-1163/breaking-change-pg-graphql-introspection-rollout) - Companion platform PR: https://github.com/supabase/platform/pull/32954 <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Documentation** * Added “Upgrading to pg_graphql 1.6.0” and updated pg_graphql docs: introspection is disabled by default, how to re-enable per schema, verification steps, and affected tools. * **New Features** * Upgrade settings UI now shows validation warnings about introspection with links to upgrade notes. * **Chores** * Added "GraphiQL" to MDX spelling allow list and added upgrade-warning types to API surface. <!-- review_stack_entry_start --> [](https://app.coderabbit.ai/change-stack/supabase/supabase/pull/46096?utm_source=github_walkthrough&utm_medium=github&utm_campaign=change_stack) <!-- review_stack_entry_end --> <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Joshen Lim <joshenlimek@gmail.com> |
||
|
|
fac7bbbf21 |
Surface errors from logs.all.otel endpoint (#46094)
## Context If an error somehow occurs on the logs.all.otel endpoint for unified logs, the network request still returns a 200 but the error is then returned in the response as such: <img width="681" height="269" alt="image" src="https://github.com/user-attachments/assets/62bcf68f-8a8c-46a0-a91a-17f653004fa0" /> In which case, there's currently no UI error handling in unified logs, and it'll just show no results. Changes in this PR addresses that: <img width="1450" height="956" alt="image" src="https://github.com/user-attachments/assets/1b2c166b-d3d1-4923-9e35-51bad99b6e1c" /> <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Bug Fixes** * Enhanced error handling and messaging for log retrieval—displays explicit error notifications when queries fail instead of misleading empty state messages, improving user experience and clarity during troubleshooting. <!-- review_stack_entry_start --> [](https://app.coderabbit.ai/change-stack/supabase/supabase/pull/46094?utm_source=github_walkthrough&utm_medium=github&utm_campaign=change_stack) <!-- review_stack_entry_end --> <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
|
5d9cf3971f |
fix(studio): improve memory and swap units in DB reports (#45889)
Fixes [DEBUG-94](https://linear.app/supabase/issue/DEBUG-94) ## Summary - **Min MB units**: Added \`formatBytesMinMB\` helper that always formats byte values in at least MB. Applied to RAM and swap y-axis tick formatters, tooltips, and chart headers. - **Swap chart scale**: Every Supabase compute instance is provisioned with **1 GB of swap regardless of size** (per [docs](https://supabase.com/docs/guides/troubleshooting/memory-and-swap-usage-explained-aPNgm0)), so the swap y-axis always shows at least 0 to 1 GB. Low swap usage no longer fills the full chart height. Removed the show/hide limit toggle since the limit is implicit in the y-axis scale. - **Swap units in header/tooltip**: Fixed all three formatters (initial header, hover-sync header, tooltip) to use \`formatBytesMinMB\` for swap so the value always shows a unit like "2.00 MB". - **Reference-line defensive fix**: Added a \`customValue\` fallback in \`useAttributeQueries\` so future reference-line attributes that use \`customValue\` instead of \`value\` are not silently overwritten to 0. ## Test plan - [ ] Open DB Reports and verify RAM/Swap y-axis labels show MB (or GB for large values), never KB or bytes - [ ] Hover a bar in the swap chart and verify tooltip and header show the same value with a unit (e.g. "2.00 MB") - [ ] With low or zero swap usage, the chart bars are flat and the y-axis goes 0 to 1 GB - [ ] CPU chart limit toggle still renders at 100% (regression check on the \`useAttributeQueries\` fallback change) 🤖 Generated with [Claude Code](https://claude.ai/claude-code) --------- Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com> |
||
|
|
9dc3998fa0 |
RLS Tester sandbox environment (#45839)
## Context Resolves FE-3221 Heavily inspired by what @filipecabaco has done previously here: https://github.com/supabase/supabase/pull/45360 This PR explores the use of pglite to set up a sandbox for RLS testing, which will pave the way for testing mutation based queries so to ensure no disruption to the actual database. Sandbox can be set up within the RLS tester panel as such: <img width="500" alt="image" src="https://github.com/user-attachments/assets/0cfdf8e4-dd99-4dee-ac00-39a32b375c07" /> Which the sandbox will mimic the project's database to the bare minimum required - entities from the `public` schema are copied over (types, tables, functions, policies) - `auth` schema is pseudo setup with `SANDBOX_SETUP_STATEMENTS` - Enough to support role impersonation + querying tables with references to the auth schema (e.g users table) - data is seeded up to 100 rows for each table - More info RE limitations in the last section below Once sandbox is ready, you'll see this UI where you can either leave the sandbox, or re-sync the sandbox from the actual database <img width="500" alt="image" src="https://github.com/user-attachments/assets/d07ce55f-5bc8-4722-8ce9-898b9b458f9b" /> Changes are currently feature flagged, so won't be available publicly just yet until things are ironed out and ready ## To test - [ ] Verify that setting up sandbox works - [ ] Verify that you can query your sandbox, and queries do not touch the actual database (can verify that we're not sending HTTP requests to the /query endpoint) - [ ] Verify correctness of RLS tester as well, should match correctness with testing against actual DB - [ ] Verify that re-syncing sandbox picks up changes - Can test by updating your policies that will affect the output of your select query - e.g SELECT for `authenticated`, change from just `true` to `false` - [ ] RLS tester should work as per normal (against actual DB) with the feature flag off with no additional overhead Let me know of any edge cases you might run into while testing ## Known quirks that will be addressed subsequently Leaving these for now just to not bloat this PR further - Pglite schema needs to be re-synced if updating RLS policies while testing, to ensure that pglite gets the updated policies. Will think about how to make this more seamless - Sandbox has its own limitations, will need to add a dialog to inform users how the sandbox works and what limitations to note of - e.g only the auth schema is mimicked - so policies that reference storage helpers won't work (although i think auth is probably the main use case and the rest might be niche) - We can slowly expand tho where required - Eventually we'll also move forward with figuring out testing mutation queries with this sandbox <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * RLS tester gains an isolated Postgres sandbox with schema/seed import, start/refresh/exit controls, and pre-populated auth data. * Sandbox management UI with setup, loading, active, and error states; refresh and destroy actions. * **Bug Fixes** * Role impersonation now keeps the PostgREST role set to anon while the tester sheet is open. * **Chores** * Content Security Policy updated to allow sandbox/connectivity endpoints. * **Style** * Minor sheet styling adjustment (top border). <!-- review_stack_entry_start --> [](https://app.coderabbit.ai/change-stack/supabase/supabase/pull/45839) <!-- review_stack_entry_end --> <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
|
85743d7215 |
feat: branching support for temporary access (#45411)
## 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? feature ## Additional context Needs API deployment, adds a toggle to allow roles to only be available on branch projects <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Added a "Branches only" option for JIT database access grants; included when grants are submitted. * **UI** * Configuration UI shows an informational notice and hides temporary-access controls when preview branches are managed from the main branch. * Feature preview label changed to "Temporary access"; badge text now reads "Preview". * **Tests** * Unit test updated to cover branches-only serialization. <!-- review_stack_entry_start --> [](https://app.coderabbit.ai/change-stack/supabase/supabase/pull/45411?utm_source=github_walkthrough&utm_medium=github&utm_campaign=change_stack) <!-- review_stack_entry_end --> <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Danny White <3104761+dnywh@users.noreply.github.com> Co-authored-by: Joshen Lim <joshenlimek@gmail.com> |
||
|
|
f45a6085f4 |
feat(studio): add auth email template reset flow (#45572)
## What kind of change does this PR introduce? Feature. Resolves AUTH-879. ## What is the current behavior? Studio does not provide a way to reset an Auth email template back to the default subject and body once it has been customised. ## What is the new behavior? Studio shows a `Reset template` action when Platform reports that the selected Auth email template subject or body has been customised. The action opens a confirmation dialog, calls the dedicated Platform reset endpoint, and refreshes the editor with the default subject and body returned by the API. The Auth config save/reset mutations now run their user-facing success handling before refreshing Auth lint data, so the success toast and local editor cleanup are not delayed by lint refetches. ## Additional context Depends on supabase/platform#32417. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Reset email templates to defaults via a confirmation dialog; button appears when custom content is detected and respects update permissions. * Typed email-template definitions and improved template variable display and descriptions. * **Tests** * Added tests covering template reset visibility, confirmation flow, state updates, permission handling, and toast notifications. * **Documentation** * Example email template placeholders updated for internationalization and provider snippets. <!-- review_stack_entry_start --> [](https://app.coderabbit.ai/change-stack/supabase/supabase/pull/45572) <!-- review_stack_entry_end --> <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Joshen Lim <joshenlimek@gmail.com> |
||
|
|
12869fcd9f |
studio: flip executeSql signature to SafeSqlFragment (7/7) (#46007)
## Summary Final PR in the SafeSql migration stack. Stacked on top of #46006. Tightens `executeSql`'s `sql` parameter from `string` to `SafeSqlFragment`. Any future raw-string caller is now a compile error — the SafeSql safety property becomes structural rather than convention-based. Also adapts the AI `execute_sql` tool to promote AI-generated SQL via `acceptUntrustedSql(untrustedSql(sql))` inside the `execute` callback. The tool's existing \`needsApproval: true\` gate ensures `execute` only runs after the user has explicitly approved — that approval is the gesture that promotes untrusted to safe. ## Test plan - [x] `pnpm typecheck` passes - [x] Grep for any remaining raw-string `executeSql` calls in `apps/studio` returns nothing - [x] Dev-server smoke: AI tool approval flow executes SQL |
||
|
|
2d4e87f579 |
studio: SafeSql for reports, query performance, privileges (4/7) (#45998)
## Summary Part 4 of the SafeSql migration stack ([#45897](https://github.com/supabase/supabase/pull/45897), [#45903](https://github.com/supabase/supabase/pull/45903), [#45990](https://github.com/supabase/supabase/pull/45990), this PR, …). Converts the remaining reports, query performance, observability, index advisor, and privileges call sites of `executeSql` to produce `SafeSqlFragment` values. The `ReportQuery.sql` field flips from `string` to `SafeSqlFragment`, which cascades into every consumer — landed here atomically so each branch typechecks cleanly. Touched areas: - `interfaces/Reports/*` — `ReportQuery.sql: SafeSqlFragment`, plus all report definitions/utilities updated - `interfaces/QueryPerformance/useQueryPerformanceQuery.ts` - `interfaces/Database/IndexAdvisor/*` and `data/database/{table-index-advisor,retrieve-index-advisor-result}-query.ts` - `data/privileges/{table-api-access,update-exposed-entities}-mutation.ts` - `interfaces/Storage/StoragePolicies/StoragePolicies.tsx` - `hooks/analytics/useDbQuery.tsx` - `Observability/useSlowQueriesCount.ts` + `useQueryInsightsIssues.utils.test.ts` ## Test plan - [x] `pnpm typecheck` passes - [x] `useQueryInsightsIssues.utils.test.ts` passes - [x] Dev-server smoke test: reports pages, query performance, index advisor, storage policies <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Refactor** * Reworked SQL construction and typings across reporting, query performance, index advisor, and privilege features to use safer SQL fragments, improving reliability and preventing query composition issues. * **Types** * Reporting query types were split to distinguish database vs. logs queries, enabling correct handling and validation. * **Docs/Utils** * Added a helper to consistently generate logs SQL for report hooks. * **Tests** * Updated tests to exercise the new SQL-building API. <!-- review_stack_entry_start --> [](https://app.coderabbit.ai/change-stack/supabase/supabase/pull/45998) <!-- review_stack_entry_end --> <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
|
e925385415 |
studio,pg-meta: SafeSql for functions/policies/triggers (3/7) (#45990)
## Summary
Third PR in the SafeSql migration stack. Flips the input/output types on
`pgMeta.functions/policies/triggers`'s `.create/.update/.remove` to use
`SafeSqlFragment`, and updates every Studio consumer atomically.
### pg-meta
- `pgMeta.functions/policies/triggers` `.create/.update/.remove` now
return `{ sql: SafeSqlFragment }` and accept branded input parameters
(`PGFunctionCreate`, `PGSavedFunction`, `PolicyCreate/UpdateParams`,
`PGTriggerCreate` with branded condition).
- `QueryModifier.toSql()` returns `SafeSqlFragment`.
### Studio consumers updated to the new branded API
- `data/database-functions/*` (query, create/update/delete mutations)
- `data/database-policies/*` (create, update mutations)
- `data/database-triggers/database-trigger-update-transaction-mutation`
- `components/Database/Triggers/TriggerSheet`
- `components/Database/Functions/CreateFunction`
- `components/Auth/Policies/PolicyEditorPanel`
These consumers land atomically with the pg-meta API change because the
input-type strictness flip (string → `SafeSqlFragment` for SQL fields)
forces every call site to update together.
## Stack
- 1/7: #45897 (merged)
- 2/7: #45903 (merged)
- 3/7: this PR
- 4/7–7/7: upcoming
## Test plan
- [x] `pnpm typecheck` passes
- [x] `pnpm --filter @supabase/pg-meta test` passes
- [x] Dev-server smoke test: function editor, policy editor, trigger
sheet
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Refactor**
* Strengthened SQL safety across policy, function, and trigger workflows
by converting raw SQL strings to typed SQL fragments and safer
composition
* Updated editor behavior to handle policy conditions/checks as typed
SQL fragments with improved initialization and template handling
* Aligned query and modifier interfaces to return typed SQL fragments
for safer composition
* **Tests**
* Updated tests to use typed SQL fragments and synchronous builders
where applicable
<!-- review_stack_entry_start -->
[](https://app.coderabbit.ai/change-stack/supabase/supabase/pull/45990)
<!-- review_stack_entry_end -->
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
|
||
|
|
88c43b31b9 |
Support optionally remove custom domain addon when deleting custom domain after activated (#45880)
## Context Related BE PR: https://github.com/supabase/platform/pull/32693 Add support to remove the custom domain add-on when deleting a custom domain after the custom domain is activated. <img width="411" height="310" alt="image" src="https://github.com/user-attachments/assets/23d57fc0-f760-42d4-8383-480ff2b2ec5a" /> We previously had this behaviour by default to address some customer feedback RE confusion that they were still being charged for custom domain add-on despite deleting the custom domain, but not removing the add-on. However this was a bit of confusing UX (RE deleting the add-on implicitly), so this makes the deleting of the custom domain add-on an explicit action instead. ## To test - [ ] Set up custom domain on a project - [ ] Trying deleting the custom domain after activating _without_ removing the add-on - [ ] Trying deleting the custom domain after activating _with_ removing the add-on |
||
|
|
d79a276824 |
studio: ColumnTypeRef cascade + FK type comparison fixes (2/7) (#45903)
## 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? Refactor + bug fixes (part of the SafeSql migration stack — PR 2 of 7, stacks on top of #45897). ## What is the current behavior? - `pgMeta.columns.create` and the table-editor SQL builder take column type as a string with array suffix and schema baked in (e.g. `'private.test_enum'`, `'int4[]'`). - The studio table-editor SQL emits the legacy schema-embedded `format` string for enums in non-public schemas, while the pg-meta columns SQL already returns the new shape (bare `format` + separate `format_schema`). The two queries disagree on how to represent the same column, surfacing as a false-positive type mismatch in the FK selector when both ends are an enum from a non-public schema. - The FK selector compares column types by `format` alone — same-named enums in different schemas appear equal, and arrays vs. scalars of the same base type pass the family check. - `displayColumnType` renders arrays as the raw `_typname` pg-meta emits (e.g. `_int4` instead of `int4[]`). ## What is the new behavior? **pg-meta** - Introduce `ColumnTypeRef` (`{ schema?, name, isArray? }`) for column type input, replacing the legacy string-with-array-suffix format. `pgMeta.columns.create` and the table-editor SQL builder consume the new shape. - Add `format_schema` to the column zod schema; pg-meta SQL emits the type's schema for the table editor's ColumnType dropdown. - `pgMeta.columns.create` returns a `SafeSqlFragment`. - Studio table-editor SQL now emits bare `format` + `format_schema`, matching pg-meta's columns SQL. **Studio** - `SafePostgresColumn`/`SafePostgresTable` extend the new `PG*` types (master dropped postgres-meta). - Pipe `ColumnTypeRef` through `SidePanelEditor` → `ColumnEditor` → `TableEditor`, along with the column-create mutation, table retrieve/list queries, and the `TableList`/`ColumnList` surfaces. - `displayColumnType` helper renders arrays as `type[]` (or `schema.type[]`) and handles non-implicit schemas. - FK selector now carries `sourceIsArray`/`targetIsArray` and compares the full `(format, format_schema, isArray)` triple. Family checks for numeric/text/uuid skip when either side is an array (FKs across array boundaries are never compatible). - Type-mismatch and type-notice alerts pass `isArray` to the display helper. - Bundle `Policies.utils` + `Policies.types` + `sql-policy-mutation`, `PolicyEditorModal`, and `SchemaGraph` here because `SidePanelEditor` consumes `acceptGeneratedPolicy`/`AcceptedGeneratedPolicy` — splitting requires temporary overloads with no architectural payoff. ## Additional context Part of the SafeSql migration stack. Stacks on top of #45897. ### Manual test checklist Surfaces touched by this PR — please exercise each: **Table editor** - [x] Create a new table with a mix of column types (scalar, array, enum, foreign key) - [x] Add a column to an existing table; verify the type dropdown lists scalars + arrays separately and shows schema-qualified names for non-public enums - [x] Edit an existing column's type (scalar ↔ array, switch between enums in different schemas) and save - [x] Verify enum types from a non-public schema (e.g. `private.my_enum`) display as `private.my_enum` in the column list **Foreign key selector** - [x] Open the FK selector for a column and pick a target column with a matching type — no mismatch warning - [x] Pick a target column whose type differs only by schema (two same-named enums in different schemas) — should show a type-mismatch alert - [x] Pick a target column where one side is an array and the other is a scalar of the same base type — should show a type-mismatch alert (no auto-cast across array boundary) - [x] When FK target sets the column type, verify `format_schema` and `isArray` are preserved on the source column - [x] Type-mismatch and type-notice alert messages render array types as `type[]` (not `_type`) **Column list / table list** - [x] Schema-qualified type names display correctly for columns whose type lives in a non-public schema - [x] Array columns display as `type[]` (or `schema.type[]`) **Policies (bundled due to import dependency)** - [x] Open the Policies page; create/edit/delete a row-level policy via the modal - [x] Generate a policy via the AI assistant and accept it through `SidePanelEditor` — verify the accepted policy lands in the editor correctly **Schema visualizer** - [x] Open the Schemas → Schema Visualizer page; verify it renders without type errors and shows tables/relationships <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Improvements** * Support for column types in non-public schemas and richer column type presentation (includes schema and array info). * Stronger SQL safety around policies and constraints; draft policy SQL is now promoted explicitly on save. * Improved foreign-key type validation and compatibility checks using enhanced type metadata. * **Tests** * Updated snapshots and tests to reflect new column metadata and SQL fragment handling. <!-- review_stack_entry_start --> [](https://app.coderabbit.ai/change-stack/supabase/supabase/pull/45903) <!-- review_stack_entry_end --> <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
|
ec21e68eee |
studio(logs): use safe sql escaping for new logs queries (#45887)
<!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Introduced a safe SQL fragment system and helpers to build composable, validated log queries and aggregations. * **Refactor** * Rewrote unified log query builders and inspection flows to use the new safe fragments and identifier/literal validators. * **Bug Fixes** * Improved validation and error handling for filter keys and literal escaping to prevent malformed or injectable queries. * **Tests** * Added tests covering identifier quoting, value escaping, and rejection of invalid filter inputs. <!-- review_stack_entry_start --> [](https://app.coderabbit.ai/change-stack/supabase/supabase/pull/45887) <!-- review_stack_entry_end --> <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
|
897043952a |
feat: add edge function secret installation method (#45826)
Adds a new method of installation detection for partners like Doppler. Doppler creates edge function secrets with specific names (`DOPPLER_CONFIG`, `DOPPLER_ENVIRONMENT`, and `DOPPLER_PROJECT`). This method allows the dashboard to check for the presence of such a secret to show the installation status. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Support for edge-function-secret-based OAuth identification and verification. * Installation checks adapt to the selected installation method and only fetch required credentials when needed. * Integration detection can validate installations via API key prefixes or matching edge-function secret names. * **Chores** * Shared helper utilities and types exported to streamline installation checks and mappings. <!-- review_stack_entry_start --> [](https://app.coderabbit.ai/change-stack/supabase/supabase/pull/45826) <!-- review_stack_entry_end --> <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Joshen Lim <joshenlimek@gmail.com> |
||
|
|
19e0b36650 | feat(logs): migrate unified logs queries to OTEL endpoint DEBUG-71 (#45642) | ||
|
|
d4079083fc |
chore(studio): drop @supabase/postgres-meta in favor of @supabase/pg-meta (#45844)
## 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? Refactor / dependency cleanup. ## What is the current behavior? `apps/studio` lists both `@supabase/pg-meta` (workspace package) as a runtime dep and `@supabase/postgres-meta` (external npm package, `^0.64.4`) as a devDependency. The external package is used only for type imports across 44 files — there is no runtime usage and no codegen pipeline that needs it. ## What is the new behavior? Every `Postgres*` type import (`PostgresTable`, `PostgresColumn`, `PostgresPolicy`, `PostgresTrigger`, `PostgresView`, `PostgresMaterializedView`, `PostgresForeignTable`, `PostgresSchema`, `PostgresPublication`, `PostgresRelationship`, `PostgresPrimaryKey`) is replaced with its `PG*` counterpart from `@supabase/pg-meta`, and the external dep is removed from \`apps/studio/package.json\`. Top-level type re-exports were added to \`packages/pg-meta/src/index.ts\` so consumers can import directly from the package root. Two latent issues surfaced by the stricter pg-meta types are also fixed: - \`data/foreign-tables/foreign-tables-query.ts\` was casting foreign-table results as \`PostgresView[]\`; corrected to \`PGForeignTable[]\`. - \`pg-meta\`'s \`PGTrigger\` Zod schema declared \`orientation\`/\`activation\` as \`z.string()\`, inconsistent with pg-meta's own \`getDatabaseTriggerUpdateSQL\` helper that requires the narrow literal unions; tightened to \`z.enum\`. ## Additional context <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Chores** * Updated internal TypeScript type definitions across the codebase to use the latest type system from `@supabase/pg-meta`. * Removed `@supabase/postgres-meta` dependency. * Enhanced type validation for database triggers and schemas to enforce stricter constraints. [](https://app.coderabbit.ai/change-stack/supabase/supabase/pull/45844) <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
|
d143571586 |
feat(assistant): trace-level scorers + server-side tool execution with needsApproval (#45654)
## Motivation When Assistant runs a potentially destructive tool like `execute_sql`, it stops the LLM request and prompts for client-side approval and execution of the tool. After approval, a second request kicks off under a separate trace. This has made scoring and [Topics](https://www.braintrust.dev/blog/topics) classification challenging, as the generated `output` is split across stateless requests. The [span-level scoring](https://www.braintrust.dev/docs/evaluate/custom-code#score-spans) approach we've used thusfar (after the LLM call, we massage the result into an `output` payload that's stuck onto the root span) has been cumbersome and led to invalid scores / topics where only part of the assistant response is considered. It's also inefficient, as we're duplicating potentially large info (like the `search_docs` output) that already exists within the trace. An alternative to scoring spans is to [score traces](https://www.braintrust.dev/docs/evaluate/custom-code#score-traces). Braintrust [best practices](https://www.braintrust.dev/docs/evaluate/score-online#best-practices) advise: > Use span scope for evaluating individual operations or outputs. Use trace scope for evaluating multi-turn conversations, overall workflow completion, or when your scorer needs access to the full execution context. We've also received [direct guidance](https://supabase.slack.com/archives/C05QYJBLX89/p1777925770927149?thread_ts=1777905716.911979&cid=C05QYJBLX89) from their team to use this approach. ## Changes Migrates eval scorers from custom `AssistantEvalOutput` shape to trace-level scoring via `trace.getThread()` / `trace.getSpans()`, with thread parsing that scores the full latest Assistant turn and passes prior conversation separately where relevant. Moves `execute_sql` and `deploy_edge_function` from client-side execution after approval to AI SDK `needsApproval` + server-side `execute()`. SQL results returned to the model are gated by AI opt-in level, so row data is only included with `schema_and_log_and_data`; otherwise the tool returns the no-data-permissions sentinel. Adds `metadata.isFinalStep` to disambiguate multiple LLM requests within an "assistant" turn due to tool call requests/responses. For online evals, this means we should configure automations to only score traces with `metadata.isFinalStep = true` to ensure we're judging the complete generated response. Other minor kaizen changes: - Renamed `promptProviderOptions` to `systemProviderOptions` to clarify that this is associated with the "system" message and disambiguate from the root `providerOptions` - Adds `evals/trace-utils.ts` to handle Zod validation of the `unknown` span shapes from Braintrust, to more easily access typed inputs/output on tool spans. - Bumps AI SDK floor version `^6.0.116` → `^6.0.174` - Tweaked the "Conciseness" scorer to not unfairly dock points for the new `[called tool_name]` labels in serialized assistant response ## Verification In the studio staging build, I asked Assistant to create a todos table with 3 sample todos. I manually approved the `execute_sql` call and saw Assistant generate text before & after the call. In Braintrust I verified two traces were produced (see [filtered logs](https://www.braintrust.dev/app/supabase.io/p/Assistant/logs?v=Staging&tvt=trace&search={%22filter%22:[{%22text%22:%22metadata.environment%2520%253D%2520%27staging%27%22,%22label%22:%22metadata.environment%2520%253D%2520%27staging%27%22,%22originType%22:%22btql%22},{%22text%22:%22%2560Chat%2520ID%2560%2520%253D%2520%25221cb2ac45-e5e7-458c-9da4-3bf6863b8842%2522%22,%22label%22:%22Chat%2520ID%2520equals%25201cb2ac45-e5e7-458c-9da4-3bf6863b8842%22,%22originType%22:%22form%22}]})), the first with `metadata.isFinalStep = false` and the second with `metadata.isFinalStep = true`. In the Braintrust staging scorers, I ran the preview Completeness scorer on the second trace and verified it sees the complete Assistant response including markers for tool calls ([link to trace](https://www.braintrust.dev/app/supabase.io/p/Assistant%20(Staging%20Scorers)/trace?object_type=project_logs&object_id=b5214b62-ad1e-4929-9d5b-40b1daebe948&r=0ed0a4f8-8aff-4a34-bb1d-1df1d88a5070&s=ff9015f8-6bf7-4ab3-83a9-ca4e69e27e82)) <img width="1193" height="960" alt="CleanShot 2026-05-07 at 11 27 10@2x" src="https://github.com/user-attachments/assets/509d4858-c3a1-4068-986d-3aa4d5617d1a" /> I also tested the `deploy_edge_function` workflow and verified it still prompts for permission and warns on deployment of existing functions. **References** - https://www.braintrust.dev/docs/evaluate/custom-code#score-traces - https://ai-sdk.dev/docs/ai-sdk-core/tools-and-tool-calling#tool-execution-approval Supercedes https://github.com/supabase/supabase/pull/45556 and https://github.com/supabase/supabase/pull/45339 Closes AI-473 <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Tool actions (SQL execution, edge-function deploy) now require explicit user Approve/Deny before proceeding. * **Improvements** * Assistant pauses for approval responses before sending follow-ups, giving clearer control over risky actions. * Deploy/replace flows show confirmation and clearer replace warnings. * Evaluation/scoring updated to use richer trace data for more accurate assistant performance signals. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
|
420d4d0b5a |
feat(studio): add Disk IO Burst Balance chart to DB Report (#45516)
## Problem When users hit a disk IO exhaustion notification, they open the Database Observability report and find IOPS and throughput charts, but no view of the metric that actually fired the warning: the EBS burst credit balance. That signal is currently only available behind Custom Reports, so the warning feels disconnected from the visible data. > "The Dashboard actually shows them their burst budget, not their normal disk usage. It leads to a lot of confusion." — support > "Customers may receive an 'exhausting multiple resources' warning and it's confusing because all the charts are 'fine', but it's the burst credits exhaustion that fails them." — Maksym Reported in [Linear DEBUG-60](https://linear.app/supabase/issue/DEBUG-60). ## Fix Add a clearly-labeled "Disk IO Burst Balance" chart to [getReportAttributesV2](apps/studio/data/reports/database-charts.ts) plotting `disk_io_budget` (% remaining) on a 0-100 axis. Tooltip and titleTooltip explain the 5 MB/s throttle floor so users can correlate this chart with the exhaustion banner copy (also being updated in [supabase#45514](https://github.com/supabase/supabase/pull/45514)). The chart is hidden for compute variants that have dedicated I/O resources (4XL and above) since the burst credit pool does not apply there. Burstable variants (nano through 2XL) see the chart inline next to the existing IOPS and throughput charts. DEBUG-61 ("replace Disk IO Usage % chart with disk throughput") was already addressed in the V2 migration (the report only renders `disk-iops` and `disk-throughput`; the old burst-percentage chart is gone). I'll close that issue as completed once this lands. ## Test plan - [ ] Visit `/project/{ref}/observability/database` on a project running `nano`/`micro`/`small`/`medium`/`large`/`xlarge`/`2xlarge` compute. Confirm the new "Disk IO Burst Balance" chart appears between throughput and connections. - [ ] On a project running `4xlarge` or larger compute, confirm the chart is hidden (chart is omitted by `hide: !hasBurstableIO`). - [ ] Hover the chart and a data point. Confirm the title tooltip and inline attribute tooltip both surface the 5 MB/s throttle behaviour. - [ ] Series renders 0-100 on the Y-axis. 🤖 Generated with [Claude Code](https://claude.com/claude-code) <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Added a Disk IO Burst Balance chart to monitor remaining burst credits; displays percentage (0–100%) with tooltip referencing baseline throughput. Shown only for supported compute variants and when the feature flag is enabled. * **Bug Fixes / UI Improvements** * Improved chart header tooltip presentation: uses a unified tooltip, includes inline docs links when available, and avoids duplicate docs icons. [](https://app.coderabbit.ai/change-stack/supabase/supabase/pull/45516) <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Claude Opus 4.7 <noreply@anthropic.com> |
||
|
|
920571fcf7 |
feat(studio): rewrite secret key reveal flow without react-query [FE-3206] (#45792)
## Summary
Rewrites the secret API key reveal flow in `ApiKeyPill` to remove its
dependency on React Query, replacing it with a lightweight custom hook.
## Changes
- **`useRevealedSecret` (new hook)**
A simple, reusable hook that:
- Fetches the unmasked secret key via `getAPIKeysById`
- Exposes `data`, `isLoading`, `reveal()`, and `clear()`
- Keeps sensitive data in local component state (no global cache)
- **`ApiKeyPill` (refactored)**
- Removes all React Query imports (`useQueryClient`, `useAPIKeyIdQuery`,
`apiKeysKeys`)
- Uses `useRevealedSecret` for reveal / copy operations
- Preserves existing UX:
- 10-second auto-hide timer
- Permission-based gating (`canManageSecretKeys`)
- Loading states on toggle / copy
- **`api-key-id-query.ts` (cleaned up)**
- Removes the now-unused `useAPIKeyIdQuery` hook
- Retains the `getAPIKeysById` fetcher for direct use
## Motivation
The previous React Query–based flow had to aggressively disable caching
(`staleTime: 0`, `gcTime: 0`) and manually purge queries from the cache
on every interaction, which was cumbersome and leaked implementation
details into the component. A plain fetch + local state is simpler and
safer for transient, sensitive data.
## Testing
- [x] Toggle reveal on a secret API key
- [x] Verify 10-second auto-hide
- [x] Copy a secret key (both revealed and unrevealed states)
- [x] Verify restricted users cannot reveal/copy
---
Resolves [FE-3206](https://linear.app/supabase/issue/FE-3206)
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Refactor**
* Improved API key reveal/copy flow: uses a dedicated reveal/clear
mechanism, preserves permission checks and 10s auto-hide, and shows
reveal/copy failures via user-facing toasts. Copy now falls back to
masked key when needed and the reveal toggle behavior is more reliable.
[](https://app.coderabbit.ai/change-stack/supabase/supabase/pull/45792)
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
|
||
|
|
b934e148a3 |
fix(reports): replace explicit any with number in tickFormatter callbacks (#45794)
## Problem Recent database report PRs introduced `(value: any)` type annotations in recharts `tickFormatter` callbacks, pushing the `@typescript-eslint/no-explicit-any` ESLint ratchet from baseline 1014 to 1017 and blocking all PR merges. ## Fix Replace `(value: any)` with `(value: number)` in all affected `tickFormatter` callbacks across the three flagged files. Recharts always passes a number to tick formatters, so this is a safe and accurate type. ## How to test - Run `pnpm lint --filter=studio` and confirm no new `@typescript-eslint/no-explicit-any` violations appear in the three changed files - Check the ESLint ratchet count is back at or below baseline 1014 <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Refactor** * Improved type safety for Y‑axis tick formatters across observability charts (Memory, Swap, Network throughput, Disk IOPS/throughput/usage, Replication Lag), ensuring tick values are treated as numeric for more consistent chart rendering and reliability. [](https://app.coderabbit.ai/change-stack/supabase/supabase/pull/45794) <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com> Co-authored-by: Ali Waseem <waseema393@gmail.com> |
||
|
|
c29ea9a0fa | feat(reports): add swap usage chart to database report (#45746) | ||
|
|
52fccc7b3b |
feat(reports): add network throughput chart to database report (#45747)
## Problem The Database report in Observability has no view of network traffic. Inbound/outbound throughput is useful for spotting saturation, large unexpected egress, or correlating spikes with disk I/O. Closes [FE-3193](https://linear.app/supabase/issue/FE-3193/add-network-in-and-out-charts). ## Fix Add a new \`network-throughput\` chart entry to \`getReportAttributesV2\` in [apps/studio/data/reports/database-charts.ts](apps/studio/data/reports/database-charts.ts), placed right before \`disk-iops\`. Uses the existing \`network_receive_bytes\` and \`network_transmit_bytes\` infra-monitoring attributes (series already exist, no backend work needed). Pattern mirrors the \`disk-throughput\` chart: bytes-per-second Y-axis, \`stackedAreaLine\` default, same \`syncId\`. \`showMaxValue\` is \`false\` because there is no provisioned network max to render as a reference line. ## Test plan - [ ] Open \`/project/<ref>/observability/database\` and confirm a "Network throughput" chart renders with two series (Network in / Network out) and a \`bytes/s\` Y-axis. - [ ] Switch the date range and confirm the chart respects it (auto-wired via \`REPORT_ATTRIBUTES.flatMap\`). - [ ] Use the global refresh button and confirm both series invalidate with the rest. 🤖 Generated with [Claude Code](https://claude.com/claude-code) <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Added a network throughput chart that visualizes inbound and outbound network throughput metrics with real-time speed data visualization. [](https://app.coderabbit.ai/change-stack/supabase/supabase/pull/45747) <!-- end of auto-generated comment: release notes by coderabbit.ai --> Co-authored-by: Claude Opus 4.7 <noreply@anthropic.com> |
||
|
|
409a38a4ea |
[FE-3145] feat(studio): use data_api_revoke_default_privileges flag (#45683)
Swap the project-creation revoke from custom `db_sql` over to the new `data_api_revoke_default_privileges` API field. Same behaviour, just delegated to the platform so non-studio flows (branches, CLI, terraform) can apply the same revoke logic — addresses [FE-3145](https://linear.app/supabase/issue/FE-3145/swap-frontend-to-use-revoke-default-privileges-flag). Backend support landed in supabase/platform#32158 and supabase/platform#32493 (FUP that decoupled the flag from `data_api_use_api_schema`). **Changed:** - `apps/studio/data/projects/project-create-mutation.ts` — accepts `dataApiRevokeDefaultPrivileges` and forwards it as `data_api_revoke_default_privileges` - `apps/studio/pages/new/[slug].tsx` — drops the inline `buildDefaultPrivilegesSql('revoke')` injection in `dbSql`, passes the flag instead - `apps/studio/pages/integrations/vercel/[slug]/deploy-button/new-project.tsx` — same swap on the Vercel deploy-button flow - `packages/api-types/types/platform.d.ts` — adds the new field to `CreateProjectBody` **Preserved:** - The `dataApiRevokeOnCreateDefault` PostHog flag still gates the default checkbox state and telemetry — only the SQL application changes - `data_api_use_api_schema: false` stays as-is — projects keep `public` + `graphql_public` exposed, no project-shape change ## To test - Project creation form (`/new/<org>`): - With PostHog flag off: "Automatically expose new tables" defaults to checked → request body has `data_api_revoke_default_privileges: false` - Manually uncheck the box → request body has `data_api_revoke_default_privileges: true`, project ends up with revoked default grants on `public` - With "Enable Data API" off → `data_api_revoke_default_privileges: false` (no point revoking when nothing's exposed) - Vercel deploy-button flow (`/integrations/vercel/<slug>/deploy-button`): - Same checkbox behaviour as above - Migration SQL from the GitHub repo still runs as `db_sql` separately <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Added support for a dedicated `dataApiRevokeDefaultPrivileges` option during project creation. * **Refactor** * Simplified Data API privilege configuration by using a dedicated parameter instead of SQL-based management across project creation flows. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Alaister Young <10985857+alaister@users.noreply.github.com> |
||
|
|
ae66a6a9c0 |
Connect GitHub during project creation (#44884)
<img width="1289" height="863" alt="image" src="https://github.com/user-attachments/assets/d661f107-b358-4894-8531-80441d60ab91" /> GitHub integration is now available on the free plan and so we'd like to start promoting code-first workflows as much as possible. One way to do that is to set the tone straight away by asking a user to connecting their GitHub repository to a project as part of project creation. This PR: - decouples GitHub connection and repo selection into a separate component we can make use of in integration settings and project creation. - Adds new GitHub fields to project creation form and sends them off to project creation endpoint - Pre-fills project name based on repo selection To test locally: - Ensure you have GitHub integration set up locally (using ngrok etc) - Ensure you are on the connected platform branch - Open create a new project page - Connect GitHub as part of the creation form and select a repo - Create the project and wait for status to be healthy - Check project settings integrations page and ensure repo is connected Note: - this requires changes on the management api end to accept new GitHub fields - it might make sense to pull out GitHub connection/authorization from GitHub repository selection but in the current state they are tied together. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit ## Release Notes * **New Features** * GitHub repository selection now available during project creation with integrated authorization flow * GitHub connection status and compute availability indicators now displayed on project dashboard * Project name auto-populates from selected GitHub repository name when available <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Gildas Garcia <1122076+djhi@users.noreply.github.com> |
||
|
|
5082c9b35d |
chore(billing): use new balance endpoint (#45481)
New billing credits balance endpoint for improved transparency |
||
|
|
116faefcda |
studio: convert more executeSql callers to SafeSqlFragment (#45645)
## Summary - Converts ~27 `executeSql` call sites in `apps/studio/data/**` to build SQL through `safeSql` / `ident` / `literal` / `keyword` / `joinSqlFragments` instead of raw template-string interpolation. - Tightens the `useDatabaseCronJobCreateMutation` and `useDatabaseEventTriggerCreateMutation` `sql`/`query` parameter types from `string` to `SafeSqlFragment` (callers already produce one). - Updates `getDeleteEnumeratedTypeSQL` in `packages/pg-meta` to return `SafeSqlFragment`. - Fixes a bug noticed while testing where Queues integration does not correctly handle queues with uppercase names. ## Pages to manually test - Integrations > Cron Jobs - Integrations > Queues - Database > Triggers > Event Triggers - Database > Indexes - Reports > Query Performance - Storage <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit ## Release Notes * **Bug Fixes** * Queue lookups now correctly handle case-insensitive queue names. * Queue table references are now properly managed and consistently applied throughout the queue management interface. * Improved queue name display normalization in the user interface. * **Chores** * Enhanced SQL query safety across the database layer through parameterized query construction and safer templating approaches. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
|
35905e70d5 |
feat: Add a logo picker for OAuth app creation sheet (#44995)
<!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Logo field now accepts/editable logo URL, plus a new storage-based Logo Picker to select or remove images from project storage. * Full storage picker: browse buckets, columns/list views, search, drag‑and‑drop uploads, file previews (image/audio/video), and single-file selection with responsive mobile/desktop layouts. * **Refactor** * Logo submission streamlined to send the provided URL directly (legacy file-read/upload flow removed). <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
|
f648c0c274 | feat: restore a physical backup by id only (#45631) | ||
|
|
f7ea722b35 |
Consolidate grid header actions in table editor into a single row (#45504)
## Consolidate Table Editor grid header actions into a single row https://github.com/user-attachments/assets/1020c385-8fa9-4ef1-b5e7-03983111508b ## Changes involved - Index advisor, Realtime, and API docs are now behind a dropdown menu button (Treated as secondary actions) - Grid header actions shifted into the same row as filter bar (more space for data grid) - Header actions will hide while filter bar is in focus (remove distractions, more space for filter bar) ## Changes to filter bar - Filter bar will refocus when deleting a filter - Clicking on the search icon will focus on the free form input of the filter bar <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Added a “More” dropdown in grid actions to access Realtime, API docs, and Index Advisor. * New dialogs for enabling Index Advisor and toggling Realtime are now consistently managed. * **Improvements** * Improved filter focus handling with auto-refocus when conditions change and responsive header behavior. * Adjusted popover alignment, separator visuals, header/footer/pagination layout and sizing. * Filter bar now supports programmatic focus; Connect button supports icon-only mode. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Gildas Garcia <1122076+djhi@users.noreply.github.com> |
||
|
|
3f97eeea5a |
feat(studio): extend safe SQL model to policy editor and related interfaces (#45560)
## 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? Refactor / security improvement ## What is the current behavior? SQL fragments across Studio are built from plain `string` values with no type-level distinction between developer-authored SQL, DB-sourced identifiers, and user-typed or externally-influenced content. ## What is the new behavior? Extends the safe SQL model to additional Studio interfaces, using `SafeSqlFragment`, `safeSql`, `ident()`, `literal()`, `untrustedSql()`, and `acceptUntrustedSql()` from `@supabase/pg-meta/src/pg-format`: - **Policy editor**: template constants typed as `SafeSqlFragment` via `safeSql` tagged literals; Monaco editor `onInputChange` emits `untrustedSql()`; `acceptUntrustedSql()` called only at the Save gesture; roles selector emits a composed `SafeSqlFragment` via `ident()` + `joinSqlFragments()` - **Auth hooks**: grant/revoke SQL statements use `ident()` for schema and function names - **Docs description editor**: `COMMENT ON` queries use `ident()` and `literal()` for table/column/function names and values - **Cron jobs**: `cron.schedule()` call and HTTP request builder use `literal()` for all user-provided values - **GraphQL linter CTA**: `REVOKE` statement uses `ident()` for schema, table, and role - **Storage public bucket warning**: `DROP POLICY` uses `ident()` for policy name - **View security autofix modal**: `ALTER VIEW` uses `ident()` for schema and view name - **API settings**: `CREATE SCHEMA` mutation uses `safeSql` tagged literal - **Database event trigger delete**: `DROP EVENT TRIGGER` uses `ident()` for trigger name - **Database queues query**: queue list query uses `safeSql` tagged literal - **Role impersonation**: function invocation SQL uses `ident()` and `literal()` ## Manual testing checklist - Authentication > Policies - Authentication > Hooks - Integrations > Queues - Database > Event Triggers - Integrations > Cron Jobs - Table Editor > View entity security autofix - API Settings > expose schema - Linter > GraphQL exposure CTA - Docs > table/column description editor - Role impersonation (user impersonation panel) ## Additional context <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Refactor** * Replaced ad-hoc SQL string building with a safer, fragment-based SQL construction across auth, policies, integrations, storage, and DB operations to improve SQL safety while preserving behavior. * **Bug Fixes / UX** * Policy editor and code editor now propagate role and input changes more reliably, improving editor responsiveness and policy handling without UI changes. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
|
e98a302428 |
Refactor merge page into smaller components + add admonition if branch cannot be merged via dashboard (#45515)
## Context Main fix is actually just the disabled check on the "Merge branch" button We're preventing merging of branches via the dashboard if the project has GH integration + "Deploy to production" enabled (the latter we're checking via if the `git_branch` property from the main branch exists, from the GET branches API endpoint) However, the `git_branch` property persists even after disabling the GH integration (by design), and hence we were incorrectly disabling the "Merge branch" button if the user removed the GH integration. Hence the fix is to also check if the project has an active GH integration ## Other changes - Refactored the merge page into smaller components - Added an admonition to callout the "Deploy to production" + what steps to take (otherwise it's not clear at all what to do in this scenario) <img width="1451" height="524" alt="image" src="https://github.com/user-attachments/assets/9df7d432-b220-4f71-b8f4-5ed0fd426afc" /> <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Redesigned merge request page interface with dedicated components for title, subtitle, and merge actions, improving user clarity and experience. * Added GitHub production deployment restriction messaging—users cannot proceed with merge requests when this integration deployment method is enabled. * **Refactor** * Enhanced GitHub integration connection query patterns and overall code organization. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
|
aab3924eef |
Refactor Invoice estimate tooltip in plan update confirmation dialog (#45446)
## Context Main fix is to ensure that the tooltip here is scrollable - but also adding some refactors This is the org billing page when downgrading an org ### Before <img width="400" alt="image" src="https://github.com/user-attachments/assets/6094c2e6-c1bb-460f-a2d2-347c1d7d2e77" /> ### After <img width="400" alt="image" src="https://github.com/user-attachments/assets/9d0ac9a6-6e89-4758-af14-8144a8a86469" /> ## Changes involved - Use HoverCard for invoice estimate in plan confirmation dialog - Also nudge the UI a little, e.g use a separate column for the compute prices + adjust text color to improve clarity - Refactor usage of `any` for some of the TS declarations <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Added an invoice estimate tooltip in subscription settings showing monthly charges with plan fees, combined compute rows, per-project compute costs, optional compute credits, and a total monthly estimate. * **Refactor** * Simplified the plan update flow by consolidating subscription preview handling and extracting the invoice UI into the new tooltip component. * **Chores** * Improved internal type definitions for subscription preview data and pricing tier identifiers. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
|
ee5d4a9314 |
chore: remove format param from audit log query (#45466)
## 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? Cleanup after shipping https://github.com/supabase/supabase/pull/45389, the backend is now defaulting to the new v2 `format`, and made `format` param optional. So this: - removes references to `v2` naming, as this is the only format - removes the `format` query param from the audit logs API calls ## What is the current behavior? Same audit log functionality shown in https://github.com/supabase/supabase/pull/45389 ## What is the new behavior? Functionally the same behavior for audit logs. - [x] Manual test in staging ## Additional context ⚠️ Will leave the `do-not-merge` tag on until: - [ ] backend `format` optional PR lands in production. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Refactor** * Consolidated audit log type definitions and updated internal API request formatting for audit endpoints across Account and Organization audit log components. No changes to user-facing functionality or audit log display. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
|
baaf07002f |
chore(studio): add method property to integration installation events (#45473)
Add new `method` property to existing event to distinguish from server-side emitted events |
||
|
|
0433eeb5f5 |
feat(studio): mark sql provenance for safety (#45336)
Mark provenance of SQL via the branded types SafeSqlFragment and UntrustedSqlFragment. Only SafeSqlFragment should be executed; UntrustedSqlFragments require some kind of implicit user approval (show on screen + user has to click something) before they are promoted to SafeSqlFragment. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Editor and RLS tester show loading states for inferred/generated SQL and include a dedicated user SQL editor for safer edits. * **Refactor** * Platform-wide SQL handling tightened: snippets and AI-generated SQL are treated as untrusted/display-only until promoted, improving safety and consistency. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
|
4a702c4429 |
fix(studio): show effective Max IOPS in DB observability (#45363)
## Problem The Max IOPS reference line in the Database Observability report displays the provisioned disk IOPS, but its tooltip claims it shows the "Maximum IOPS for your current compute size". The real effective ceiling is `min(compute IOPS limit, provisioned disk IOPS)`. Users who upgrade their disk IOPS without upgrading compute see an inflated number and may draw incorrect conclusions about their IO headroom. Reported in [Linear DEBUG-63](https://linear.app/supabase/issue/DEBUG-63) (originally [FE-2856](https://linear.app/supabase/issue/FE-2856)). ## Fix In [apps/studio/data/reports/database-charts.ts](apps/studio/data/reports/database-charts.ts), use the existing `mapComputeSizeNameToAddonVariantId` + `COMPUTE_MAX_IOPS` lookup (already used in DiskManagement) to compute the effective ceiling and pass it as the `disk_iops_max` reference line value. Tooltip rewritten to match. ```ts const provisionedDiskIops = diskConfig?.attributes?.iops const computeIopsLimit = COMPUTE_MAX_IOPS[mapComputeSizeNameToAddonVariantId(project?.infra_compute_size)] const effectiveMaxIops = typeof provisionedDiskIops === 'number' && typeof computeIopsLimit === 'number' ? Math.min(provisionedDiskIops, computeIopsLimit) : provisionedDiskIops ``` ## Test plan - [ ] On a project where compute IOPS limit < provisioned disk IOPS (e.g. Micro compute with upgraded disk), confirm the Max IOPS reference line on `/project/{ref}/observability/database` reflects the compute limit, not the disk IOPS. - [ ] On a project where provisioned disk IOPS < compute IOPS limit, confirm the reference line still shows the disk IOPS. - [ ] Hover the line and confirm the tooltip reads "Effective maximum IOPS for your current compute and disk configuration..." 🤖 Generated with [Claude Code](https://claude.com/claude-code) <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit ## Release Notes * **Bug Fixes** * Enhanced IOPS limit calculations in database reports to account for both compute size and disk provisioning constraints, resulting in more accurate Max IOPS reference values. Improved chart tooltips to better reflect the effective combined compute and disk IOPS constraints. <!-- end of auto-generated comment: release notes by coderabbit.ai --> Co-authored-by: Claude Opus 4.7 <noreply@anthropic.com> |
||
|
|
d666b950ff |
feat: update audit log schema & UI (#45389)
## 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? - Update to the audit log schema (changes were already applied in staging) - Updates the org & project audit log page to reflect the changes to the schema - The schema should be agnostic to whether logs were emitted to logflare with the old & new schema format - the backend adjusts old logs to the new format. ## What is the current behavior? Currently, the frontend is parsing the legacy schema as the backend returns this by default. It also doesn't show some of these new fields yet. ## What is the new behavior? ### Org Audit Logs - Table View <img width="1810" height="1310" alt="CleanShot 2026-04-29 at 18 27 22" src="https://github.com/user-attachments/assets/47fec068-1ffa-4e52-bc46-3bffdef55adb" /> ### Org Audit Logs - Single log View <img width="1842" height="1494" alt="CleanShot 2026-04-29 at 18 27 37" src="https://github.com/user-attachments/assets/3cff3bdf-4a6a-4981-acaa-7f95bb3ae9cf" /> Note that the `Target` field is no longer there. We just show the `metadata` JSON. <img width="1842" height="1494" alt="CleanShot 2026-04-29 at 18 27 40" src="https://github.com/user-attachments/assets/d2e681f0-41a6-4bc7-a3d7-ec7e8101616c" /> ### Account (Profile) Audit Logs - Table View <img width="1810" height="1310" alt="CleanShot 2026-04-29 at 18 25 20" src="https://github.com/user-attachments/assets/c72e19df-9b82-4611-8889-7af463769550" /> ### Account (Profile) Audit Logs - Single log View <img width="1810" height="1310" alt="CleanShot 2026-04-29 at 18 25 32" src="https://github.com/user-attachments/assets/46f8d3b6-4f2f-4944-b891-431a93e5f3c3" /> ## Additional context ⚠️ currently leaving the `do not merge` tag on, until: - [x] I have verified it works in staging - [x] We've deployed the new schema to production <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Audit logs now use the v2 format with microsecond-accurate timestamps, improved ordering, and a revamped details panel showing clearer actor/action/request/project/org fields and fallback labels. * Page/header layout updated so audit logs render at top level with adjusted spacing. * **Refactor** * Shared sorting and filtering utilities added for consistent user/project filtering and non-mutating log sorting. * **Tests** * Added tests for timestamp conversion, sorting, filtering, and date-range formatting. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
|
688834f1eb |
fix: Fix infinite loading in the Cron jobs table (#45421)
This PR fixes an issue where the infinite list doesn't work for cron
jobs. If the initial data (20 cronjobs) renders and you have a tall
monitor to fit the entire table, the `react-data-grid` can't `onScroll`
event which fetches the next page.
To test:
1. Add 40-50 cron jobs by running `SELECT cron.schedule('test 30', '0 2
* * 1', 'select 1');` repeatedly.
2. Open the /project/_/integrations/cron/jobs
3. See if you can scroll and trigger the second page.
Fixes
https://linear.app/supabase/issue/FE-3117/cron-job-is-not-scrollable
|
||
|
|
56de26fe22 |
chore: Migrate the monorepo to use Tailwind v4 (#45318)
This PR migrates the whole monorepo to use Tailwind v4: - Removed `@tailwindcss/container-queries` plugin since it's included by default in v4, - Bump all instances of Tailwind to v4. Made minimal changes to the shared config to remove non-supported features (`alpha` mentions), - Migrate all apps to be compatible with v4 configs, - Fix the `typography.css` import in 3 apps, - Add missing rules which were included by default in v3, - Run `pnpm dlx @tailwindcss/upgrade` on all apps, which renames a lot of classes - Rename all misnamed classes according to https://tailwindcss.com/docs/upgrade-guide#renamed-utilities in all apps. --------- Co-authored-by: Jordi Enric <jordi.err@gmail.com> |
||
|
|
151a1792d9 | feat(studio): add support for new ducklake destination in replication UI (#45370) | ||
|
|
c8781c885e |
chore(studio): use new publish_dashboard column for marketplace db query (#45345)
Updates the marketplace DB query to use the new `publish_dashboard` column that was added in https://github.com/supabase/marketplace/pull/49 <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Chores** * Updated internal marketplace integration query and database type definitions to streamline listing management logic. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
|
05fc4aca13 |
chore(studio): clean up temporary access response typing (#45354)
## What kind of change does this PR introduce? Cleanup. ## What is the current behavior? Temporary access still has a couple of leftover JIT fallback messages and an unnecessary local unavailable-reason type after the Platform response types were split into `JitAccessResponse` and `JitStateResponse`. ## What is the new behavior? Studio relies on the generated `JitStateResponse` discriminated union for the toggle warning and uses temporary access copy consistently in the remaining fallback toasts. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Improvements** * Refined error messaging for temporary database access grant and revoke operations. * Enhanced condition detection for toggle failure warnings in database access configuration. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
|
bedb2efb87 |
chore(studio): JIT access UI improvements (#44161)
## What kind of change does this PR introduce? UI and copywriting improvements for temporary access. ## What is the current behavior? The temporary access UI still used older JIT/ephemeral naming in some places, did not clearly explain the setup requirements, and had to infer unavailable states from Platform error message text. ## What is the new behavior? The settings UI now uses temporary access naming consistently, explains that temporary access uses short-lived tokens for manual database connections, and renders clearer unavailable states for projects that require either a Postgres upgrade or a platform migration. The Studio query now consumes Platform’s structured `unavailableReason` contract instead of parsing human-readable error strings, so the UI owns the copy while Platform owns the eligibility reason. Validation: - `pnpm eslint components/interfaces/Settings/Database/JitDatabaseAccess/JitDbAccessConfiguration.tsx data/jit-db-access/jit-db-access-query.ts` - `pnpm tsc --noEmit --pretty false` <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * IP range input now supports one CIDR range per row with add/remove rows and form integration. * **Documentation** * Replaced “JIT” wording with “Temporary” / “Ephemeral token-based” access across UI, dialogs, toasts, and help links. * Added minimum PostgreSQL version requirement (17.6.1.081+). * **Improvements** * Per-row CIDR validation with precise nested error messages. * Refined layout spacing and moved the temporary-access configuration earlier in Database settings. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Etienne Stalmans <etienne@supabase.io> Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com> Co-authored-by: Joshen Lim <joshenlimek@gmail.com> |
||
|
|
5f867e5f6c |
Feature Preview: RLS Tester (#45121)
## Context Resolves FE-3077 Related discussion: https://github.com/orgs/supabase/discussions/45233 Verifying the correctness of your RLS policies set up has always been a gap, as highlighted by a number of GitHub discussions like [here](https://github.com/orgs/supabase/discussions/12269) and [here](https://github.com/orgs/supabase/discussions/14401). As such, we're piloting a dedicated UI for RLS testing (using role impersonation as the base), in which you'll be able to - Run a SQL query as a user (not logged in / logged in - this is the role impersonation part) - See which RLS policies are being evaluated as part of the query - And hopefully be able to debug which policies are not set up correctly Changes are currently set as a feature preview - and we'll iterate as we get feedback from everyone 🙂 🙏 <img width="613" height="957" alt="image" src="https://github.com/user-attachments/assets/83c37f8a-28fc-43b3-b0ff-e28571d8710c" /> <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * RLS Tester: run queries as anon or authenticated users, view inferred SQL, per-table policy summaries, and data previews of accessible rows. * UI preview: new RLS Tester preview card and modal with opt-in toggle; RLS Tester sheet with role/user selector and query editor. * SQLEditor: “Explain” tab is always visible. * **Chores** * Added supporting API endpoints, background checks for table RLS status, and a local-storage flag to persist the preview opt-in. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
|
67deabf67e |
fix: create etl publication as postgres (#45043)
## What kind of change does this PR introduce? Bug fix ## What is the current behavior? Creating a schema only branch fails because ETL publication is owned by `supabase_etl_admin` which users have no access. ## What is the new behavior? Since ETL supports user managed publications, create them through pgmeta so it's owned by `postgres` role instead. ## Additional context mirrors [upstream etl](https://github.com/supabase/etl/blob/main/etl-api/src/db/publications.rs#L22-L51) implementation <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Bug Fixes** * Added guards to prevent creating publications when project or connection info is missing, with clearer error logging. * Ensure the project connection string is explicitly passed so publications target the correct database. * **Refactor** * Publication creation now executes generated SQL directly against the database, with correct handling of empty or selected table lists and proper identifier quoting for reliability. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Joshen Lim <joshenlimek@gmail.com> Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com> Co-authored-by: CodeRabbit <noreply@coderabbit.ai> |
||
|
|
7f5865872a |
Enforce noUnusedLocals and noUnusedParameters in tsconfig.json + fix all related issues (#45264)
## Context Enforce `noUnusedLocals` and `noUnusedParameters` in tsconfig.json + fix all related issues |
||
|
|
8347877957 | feat(etl): Add UI elements to disable external replication (#45035) | ||
|
|
8454ec241d |
feat: add batch email org invites (#44832)
## 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? Feature ## What is the current behavior? When sending organization invites to multiple emails at once, the invitations API is called once for each email passed, passing a single email address in the `email` field. ## What is the new behavior? A single request is used when sending multiple organization invites at once, by using the new `emails` field. ## Additional context This builds further on https://github.com/supabase/supabase/pull/42637 ⚠️ Note: I'd like to merge this after getting the API changes in first: https://github.com/supabase/platform/pull/31561 <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Bulk invite: paste comma-separated emails (parsed, trimmed, deduplicated, lowercased) and send as a single batched request; inputs are categorized into new, already-invited, and existing members. * SSO and project scope options included in invite payloads. * **Bug Fixes / API** * Invitation endpoint now accepts multiple emails; resend uses multi-email format. Invalid addresses are blocked, existing members are skipped with error toasts, and overall success is reported with the dialog closing after invite. * **Tests** * Added unit and UI tests covering parsing, categorization, payload building, validation limits, and invite flows. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Danny White <3104761+dnywh@users.noreply.github.com> |
||
|
|
e6ca2766ff |
feat: show tax preview for credit top-ups (#45005)
## Summary
- Add tax preview to the credit top-up flow by integrating the new `POST
/organizations/{slug}/billing/credits/preview` endpoint
- Show a price breakdown (credit amount, tax line item, total) in the
top-up dialog before the user confirms payment
- Handle all three `tax_status` states: show tax when `calculated`, hide
the line when `not_applicable`, show an inline warning when `failed`
## Behavior
- Preview fires as soon as a valid amount (300–2000) is entered; address
and tax ID are optional and refine the estimate
- Amount and address changes are debounced at 1s to avoid excessive API
calls
## Test plan
- [ ] Open credit top-up dialog - verify preview appears with default
$300 amount
- [ ] Change amount within 300–2000 - verify preview updates after
debounce
- [ ] Enter amount outside range (e.g. 100 or 3000) - verify preview
hides and validation error shows
- [ ] Add a new payment method with a billing address in a taxed region
- verify tax line item appears
- [ ] Add a new payment method with no tax jurisdiction - verify no tax
line, just total
- [ ] Complete a top-up - verify the charge goes through and dialog
closes
<img width="571" height="551" alt="image"
src="https://github.com/user-attachments/assets/d3357752-f913-4a4a-b84a-f78e2f457c7b"
/>
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Credit top-up preview with charge breakdown (credit, tax or tax note,
total).
* Onboarding survey endpoint and ISO 27001 certificate availability for
organizations.
* **Updates**
* Improved top-up UX: debounced address/tax inputs, enforced min/max
amount validation, preview-driven form state, and submit disabled while
preview is loading/stale.
* API docs wording changed to “temporary access configuration.”
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
|
||
|
|
1ab7251060 |
chore(studio): clarify partnered orgs and projects (#44328)
## What kind of change does this PR introduce? UI improvements. - Resolves DEPR-401 - Resolves DEPR-424 - Resolves DEPR-425 ## What is the current behaviour? Studio currently blurs two different concepts together: - `billing_partner` / `billing_via_partner`, which represent real billing ownership for marketplace-managed organisations such as AWS and Vercel - Stripe connection state, which is not actually partner billing in the same sense, but was previously being mocked through the same UI paths That made the Stripe work harder to reason about and left some local behaviour dependent on temporary overrides rather than the API shape we want to ship. ## What is the new behaviour? This PR separates those concerns while keeping the existing AWS and Vercel marketplace experience intact. - AWS and Vercel continue to use `billing_partner` / `billing_via_partner` for billing ownership, lockouts, and manage CTAs - Stripe display state now comes from `integration_source`, which lets Studio show Stripe-specific badges and alerts without treating Stripe as a billing partner - organisation-level partner UI is unified across AWS, Vercel, and Stripe, including the org banner, navbar icon treatment, and organisation cards - project-level Stripe UI now appears only when the project itself is marked as Stripe-connected, including the project switcher, project list surfaces, and a project-level banner - Stripe-connected organisations are no longer incorrectly blocked behind the AWS/Vercel-style billing management alerts for invoices, billing address, payment methods, or plan changes - banner dismissal is scoped to the relevant org/project and partner/integration state ## Review order Most of the diff size here is regression tests and generated types. The behavioural changes are concentrated in a smaller set of files. Recommended review order: 1. `integration_source` vs `billing_partner` data-model split and org/project query mapping 2. org-level UI: partner icon, org banner, org dropdown/card treatment 3. billing gating updates for Stripe vs AWS/Vercel 4. project-level Stripe UI: dropdown, list surfaces, banner 5. tests and generated types | Stripe Org(s) | | --- | | <img width="1024" height="759" alt="Organizations Supabase" src="https://github.com/user-attachments/assets/d0ef338c-3b41-4c6d-b3bd-f21a2c182840" /> | | Vercel Org(s) | | --- | | <img width="1024" height="759" alt="Organizations Supabase" src="https://github.com/user-attachments/assets/1dc57770-3f24-45ac-840f-34680555cde8" /> | | AWS Org(s) | | --- | | <img width="1024" height="759" alt="Organizations Supabase" src="https://github.com/user-attachments/assets/7847dad0-ee30-4a65-ab0b-b3b16af0d34f" /> | | Stripe Org, Non-Stripe Project | | --- | | <img width="1152" height="885" alt="Mallet Toolshed Supabase-1673E019-792C-462C-B6F8-C5DDB810B331" src="https://github.com/user-attachments/assets/556fbea3-b5ae-4f2f-96b9-6f66c6654e4a" /> | | Stripe Org, Stripe Project | | --- | | <img width="1152" height="885" alt="Hammer Toolshed Supabase-7E86C17C-561F-4221-BD16-EAFF7D41AAE0" src="https://github.com/user-attachments/assets/94f8daf6-0320-413e-8d56-59f9acaaea15" /> | | Vercel Org | | --- | | <img width="1024" height="759" alt="Projects Toolshed Supabase-A7891653-9366-4B99-89DD-789D70CD52E3" src="https://github.com/user-attachments/assets/c87ee6e8-4451-4866-a905-23a38b2593e3" /> | | AWS Org | | --- | | <img width="1024" height="759" alt="Projects Toolshed Supabase-58A43ECE-569E-4541-9463-346A90B02CFF" src="https://github.com/user-attachments/assets/9350a180-4d58-42a1-ad1a-95893c2e8b12" /> | This also removes the old Stripe mock override path in Studio so the frontend matches the intended API model more closely. ## ~~Dependencies~~ (merged!) This work depends on the private platform change that exposes `integration_source` on the relevant organisation and project payloads: - https://github.com/supabase/platform/pull/31874 _Update: now merged._ ## Local testing ### Stripe If you have the private `platform` repo checked out locally, make sure your local API returns `integration_source: 'stripe_projects'` consistently for the Stripe-linked org/project you are testing. Important responses: - `/platform/organizations` - `/platform/organizations/:slug/projects` - `/platform/projects/:ref` Verify: - org banner and org icon show the Stripe connected state - unopened and opened project switcher both show Stripe only for Stripe-linked projects - project cards / table rows show the Stripe chip only for Stripe-linked projects - the project-level Stripe banner appears across project surfaces - billing address, tax ID, invoices, payment methods, and plan changes remain editable in Studio for Stripe orgs ### Vercel Use a Vercel Marketplace org with real `billing_partner` / `billing_via_partner` values. Important org-level endpoints for local mocking in `platform`: - `/platform/organizations` - `/platform/organizations/:slug` - `/platform/organizations/:slug/billing/subscription` Project-level Vercel indicators still come from `/platform/integrations/:slug`, not `integration_source`. ### AWS Use an AWS Marketplace org with real `billing_partner` / `billing_via_partner` values. Important org-level endpoints for local mocking in `platform`: - `/platform/organizations` - `/platform/organizations/:slug` - `/platform/organizations/:slug/billing/subscription` AWS does not currently have a Stripe-like project-level indicator in these org/project payloads. ## Notes - `billing_partner` is no longer the right abstraction for the Stripe-connected case in this PR. It remains the source of truth for marketplace billing ownership, while Stripe currently uses `integration_source` as a connection/display signal. - I re-ran `pnpm api:codegen` while tightening this PR and kept only the generated type changes this branch actually depends on, to avoid unrelated API drift in the review. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Stripe Projects integration added for billing and project flows * Partner icons/badges shown across org and project lists, dropdowns, and rows * Dismissible, partner-specific marketplace/integration banners with contextual CTA behavior * Improved partner-billing detection to drive billing UI and invoice/plan availability * **Tests** * Extensive new test coverage for billing UI, partner-managed fallbacks, banners, icons, and related flows <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com> Co-authored-by: Ivan Vasilov <vasilov.ivan@gmail.com> |