mirror of
https://github.com/supabase/supabase.git
synced 2026-10-05 17:35:10 +03:00
support-policy-changes
6599
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 Artur ZakirovandCharis
|
4b2d163a1d |
fix(orioledb): use alpha and beta conditionally based on AMI version (#51162)
## Problem - Older orioledb projects show "Public Beta" instead of "Public Alpha" in UI. - List of backups in the "Scheduled backups" tab hangs. ## Solution - show in the UI "Public Alpha" for projects older than 17.11.0.001-orioledb - show in the UI "Public Beta" for new projects - enable scheduled-backup query for "Public Beta" <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Bug Fixes** * Backup availability messages now reflect OrioleDB’s current release stage rather than always describing it as public beta. * AWS backup queries are no longer disabled for every OrioleDB project; they remain disabled during the alpha stage. * **New Features** * Added an informational notice and documentation link for scheduled backups on AWS OrioleDB projects in alpha. * Added release-stage details to the PITR availability notice. <!-- end of auto-generated comment: release notes by coderabbit.ai --> Co-authored-by: Charis <26616127+charislam@users.noreply.github.com> |
||
|
Anthony Lio
|
b13d6c2878 |
feat(chore): add a lint ratchet for shadcn rules (#51014)
## Problem shadcn lint rules has been soft landed in #50676 and are now on as warnings in every app, but nothing stops a PR from adding new violations linear: FE-4473 ## Solution - moved the ratchet script and its tests from `apps/studio/scripts` to `packages/eslint-config-supabase` so every app runs one copy - added a shared rule list, `packages/eslint-config-supabase/ratchet-rules.json` with the shadcn rules - www, docs, design-system, ui-library and learn get `lint-ratchet.yml` with one job per changed app (triggered by the app, `packages/**` or the lockfile) + a weekly `lint-ratchet-decrease.yml` (as for studio ratchet) - package tests run in `eslint-config-supabase-tests.yml` <!-- ## Preview links If relevant, include links to changed pages for easy review access. Copy the preview base URL from the Vercel bot comment on this PR. Use the following table as an example template. | Site | Live | Preview | Search for | | -------------- | ------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------ | ----------------------------- | | WWW | [/blog/your-post](https://supabase.com/blog/your-post) | [/blog/your-post](https://zone-www-dot-com-git-branch-name-supabase.vercel.app/blog/your-post) | unique phrase from the change | | Docs | [/docs/guides/your-page](https://supabase.com/docs/guides/your-page) | [/docs/guides/your-page](https://docs-git-branch-name-supabase.vercel.app/docs/guides/your-page) | unique phrase from the change | | Studio | [/dashboard](https://supabase.com/dashboard) | [/dashboard](https://studio-git-branch-name-supabase.vercel.app/dashboard) | unique phrase from the change | | Design system | [/design-system](https://supabase.com/design-system) | [/design-system](https://design-system-git-branch-name-supabase.vercel.app/design-system) | unique phrase from the change | | UI library | [/library](https://supabase.com/library) | [/library](https://ui-library-git-branch-name-supabase.vercel.app/library) | unique phrase from the change | | Knowledge base | [/kb/guides/your-page](https://supabase.com/kb/guides/your-page) | [/kb/guides/your-page](https://kb-git-branch-name-supabase.vercel.app/kb/guides/your-page) | unique phrase from the change | --> <!-- ## Additional context Optionally add any other context or screenshots. --> ## Review instructions 1. run `pnpm --filter ./apps/www run lint:ratchet` 2. add `p-[13px]` to a `className` in any www component and run it again. it fails with `shadcn/no-arbitrary-values` and the file name with `(+1)` 3. revert change 4. run `pnpm --filter eslint-config-supabase test` and see 6 tests pass 5. in ci, check `Ratchet studio lint checks` and the `ratchet (<app>)` jobs for the apps this pr touches ## Checklist Check all before review: - [x] I have read [CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/CONTRIBUTING.md) - [x] If I wrote a new docs topic or edited an existing topic, I used the `/write-the-docs` or `/edit-the-docs` skill, which applies the docs [style guide](https://github.com/supabase/supabase/tree/master/apps/docs/style-guide) <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Developer Improvements** * Expanded automated lint checks to cover additional apps and shared package changes. * Added checks for arbitrary Tailwind values, unknown classes, and raw colors across supported apps. * Added automated baseline updates that can open or update a pull request when lint counts change. * Added tests for the lint configuration and support for combining multiple rule files. * Updated Studio lint notifications to exclude Shadcn rules with zero-baseline counts. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
Danny White
|
6143441493 |
fix(pipelines): clarify DuckLake destination setup (#51013)
## Problem The DuckLake setup form makes it hard to choose between Supabase projects and external connection details. Bucket creation, catalog settings, and the guide do not clearly follow the setup flow. ## Solution - Show **Configuration method** as two clear choices: **Select Supabase projects** and **Enter connection details**. - Group catalog and storage fields, move **Pool size** to **Advanced settings**, and add **New bucket** to the bucket selector. - Clarify the custom Postgres and S3 fields, including the metadata schema, connection URL, and storage options. - Update the [DuckLake destination guide](https://docs-git-dnywh-ducklake-pipelines-setup-supabase.vercel.app/docs/guides/database/replication/pipelines/ducklake) to follow the form and explain resource preparation and validation. | Before | After | | --- | --- | | <img width="1280" height="1323" alt="50587" src="https://github.com/user-attachments/assets/bf5997cf-9fc4-48a8-ad4f-13fa991d56f9" /> | <img width="1280" height="1323" alt="61914" src="https://github.com/user-attachments/assets/2c1dd7ef-797f-4302-9e2e-93a5f1e6e515" /> | ## Review instructions 1. Open **Database > Pipelines > Add pipeline** and select **DuckLake**. 2. Select **Select Supabase projects**. Check the catalog and storage fields, create a bucket from the bucket selector, and find **Pool size** under **Advanced settings**. 3. Select **Enter connection details**. Check the Catalog URL, S3 URL style, and Use SSL guidance. 4. Compare both routes with the [DuckLake destination guide](https://docs-git-dnywh-ducklake-pipelines-setup-supabase.vercel.app/docs/guides/database/replication/pipelines/ducklake). ## Checklist - [x] I have read [CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/CONTRIBUTING.md) - [x] I used the `/edit-the-docs` skill and the docs [style guide](https://github.com/supabase/supabase/tree/master/apps/docs/style-guide) <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * DuckLake destinations support Supabase-managed projects or an existing Postgres catalog with S3-compatible storage. * Select a storage bucket using search, configure a metadata schema, and access clearer guidance for catalog and storage settings. * Advanced settings provide a connection pool size from 1 to 6, with a default of 4. Credential fields include show and hide controls. * **Documentation** * Updated setup steps, configuration guidance, query credential details, and troubleshooting instructions for both configuration modes. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
Kody JacksonandIvan Vasilov
|
6572fad288 |
fix(studio / ui) - update xss vuln version of tanstack (#51141)
## Problem When I bumped the pnpm-lock file in an unrelated KB fix (#51132), I believe that refreshed the build cache (either that, or Vercel started flagging this issue very recently). At any rate, builds are now failing b/c of a [vulnerable Tanstack/react-start package](https://github.com/TanStack/router/security/advisories/GHSA-qx66-fv34-fjm8), which this PR attempts to fix. ``` The build blocks vulnerable @tanstack/react-start@1.168.18 due to an XSS security check. ``` <img width="1355" height="397" alt="image" src="https://github.com/user-attachments/assets/7d0d90fb-009c-4a0b-aadc-b526e0fcce0a" /> <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Chores** * Updated project maintenance settings and supporting TanStack package versions. * Improved error reporting so standard errors include their stack trace, while other error values are logged directly. * No app features were added or removed. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Ivan Vasilov <vasilov.ivan@gmail.com> |
||
|
Monica Khoury
|
123c768de1 |
Warn when authenticator role overrides exposed schemas (FE-4472) (#50982)
## What Adds a warning in Project Settings > API when the `authenticator` role's `pgrst.db_schemas` setting overrides the Dashboard's "Exposed schemas" configuration, plus an inline "Reset override" button to fix it in one click. ## Why `ALTER ROLE authenticator SET pgrst.db_schemas = ...` silently overrides what PostgREST actually exposes, regardless of what's selected in the Dashboard. Users hit a confusing PGRST106 error with no indication that a role-level override is the cause. ## How - New query (`authenticatorRoleConfigQueryOptions`) reads `pg_roles.rolconfig` for the `authenticator` role and parses out any `pgrst.db_schemas` value. Configured to always refetch on mount and window focus, since the fix is often applied outside the Dashboard (SQL editor, another client) with no cache-invalidation event for the app to react to. - `PostgrestConfig.tsx` compares that value against the currently selected schemas and shows an `Admonition` warning naming the actual overriding schemas, with a link to the PGRST106 troubleshooting guide, when they differ. - The warning includes a "Reset override" button that runs `alter role authenticator reset pgrst.db_schemas` after a confirmation step (showing the exact SQL that will run, with a copy button), then refetches so the warning clears immediately without a page reload. ## Testing 1. In the SQL Editor of a test project, run: ```sql alter role authenticator set pgrst.db_schemas = 'public'; ``` 2. Go to Project Settings > API, and select a schema other than (or in addition to) `public` in "Exposed schemas" (e.g. add `api`). 3. The new warning should appear, naming `public` as the schema actually in effect, with a link to the PGRST106 troubleshooting guide. 4. Click "Reset override" in the warning, confirm in the modal, and check that the warning clears immediately without a page reload. 5. Alternatively, clear the override manually from the SQL editor: ```sql alter role authenticator reset pgrst.db_schemas; ``` then navigate away from the API settings page and back (or refocus the browser tab) — the warning should clear without a hard refresh. Fixes [FE-4472](https://linear.app/supabase/issue/FE-4472/warn-when-authenticator-role-overrides-exposed-schemas) <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * The API settings page now warns when the authenticator role’s exposed schemas differ from the saved Dashboard configuration. * You can reset the override to restore the saved schema configuration. The reset requires permission and provides success or error feedback. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
Danny White
|
4f0be099e7 |
fix(studio): restore the Snowflake destination mark (#51075)
## Problem The Snowflake destination still uses a neutral text monogram even though its Studio asset is available. Supporting that monogram also leaves a separate rendering path used by no other destination. ## Solution Restore Snowflake through the shared brand-icon registry introduced by #51073. Simplify `DestinationLogo` back to a map of destination marks, removing the monogram type, configuration, and rendering branch. | After | | --- | | <img width="924" height="730" alt="CleanShot 2026-09-30 at 15 14 59@2x" src="https://github.com/user-attachments/assets/7409d483-3371-45ec-bf54-0ddc6ad22857" /> | ## Review instructions 1. Open `/project/<ref>/database/replication` with a Snowflake pipeline. 2. Confirm the Snowflake mark appears in the pipeline list and diagram. 3. Open the pipeline child route and confirm the same mark appears in its header. 4. Confirm the other destination marks remain unchanged in light and dark themes. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Visual Updates** * Snowflake replication destinations now display a themed brand icon instead of the “SF” monogram. Other destinations retain their existing icons. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
Joshen Lim
|
d6c81b66c9 |
Apply scrollBeyondLastLine for CodeEditor in QueryEditor and Logs Explorer (#51082)
## Context As per PR title - this was the behaviour for the SQL Editor and figured it makes sense to also have this behaviour in the Explorer QueryEditor + Logs Explorer where the main UX is writing queries, and lets the user bring the active section of the code closer to the middle of the viewport (rather than right at the bottom) <img width="790" height="305" alt="image" src="https://github.com/user-attachments/assets/07eb63fa-1bb9-4abe-859e-2968a73e7ca5" /> <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Editor Improvements** * Query editors now allow scrolling beyond the final line, providing more room to position the last lines on screen. * The SQL editor no longer forces the decoration area to zero width; it now uses Monaco’s default width behavior. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
Danny White
|
5fbf1ac4ff |
feat(studio): support themed pipeline destination logos (#51073)
## Problem Some destination marks need different assets to maintain contrast across light and dark surfaces. Their paths are also duplicated between Pipelines and Wrappers. ## Solution Add a shared brand-icon registry that supports either one asset or light and dark variants. Pipeline destination logos resolve against the active theme, while Wrappers continue using the light variant for their white logo tiles. This keeps single-asset destinations unchanged and preserves the existing monogram treatment where applicable. | Light | Dark | | --- | --- | | <img width="926" height="742" alt="CleanShot 2026-09-30 at 15 03 31@2x" src="https://github.com/user-attachments/assets/d76e5995-1bb8-4cb7-b991-c5dc1a5d8cb0" /> | <img width="926" height="732" alt="CleanShot 2026-09-30 at 15 03 03@2x" src="https://github.com/user-attachments/assets/83d45f30-3bf6-4ddc-8607-e27628cb4966" /> | ## Review instructions 1. Open `/project/<ref>/database/replication` with pipelines using the themed destination marks. 2. Switch between light and dark themes from the account menu. 3. Confirm each themed mark swaps assets and remains legible in the pipeline list, diagram, and child-route header. 4. Open Database Integrations and confirm the corresponding Wrapper tiles continue using their light-surface assets. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Style** * Updated the BigQuery, ClickHouse, DuckLake, and Snowflake icons in integration and replication views to use branded marks. Icons now use theme-appropriate variants where available, helping them display consistently across light and dark themes. ClickHouse’s previous “CH” monogram is replaced with its branded mark. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
Artur Zakirov
|
bd9a0ff4e6 |
feat(orioledb): rename orioledb from Public Alpha to Public Beta in dashboard (#50975)
## Problem We need to rename orioledb in Dashboard. ## Solution - Update Studio copy/badges referencing OrioleDB from "Public Alpha" to "Public Beta" (project creation advanced config, restore-to-new-project, PITR empty state) - Remove the scheduled-backups block that hid backups for OrioleDB projects — OrioleDB now has WAL-G scheduled backups in beta, so that page should behave normally. PITR keeps its existing guard since PITR is not yet supported for OrioleDB. - Update the `useOrioleDb` telemetry property doc-comment to reflect the beta status - Update project-creation wizard test expectations/fixtures accordingly (`release_channel: 'beta'`) Marketing (`apps/www`) and docs (`apps/docs`) references to OrioleDB alpha status are being updated separately. <!-- ## Preview links If relevant, include links to changed pages for easy review access. Copy the preview base URL from the Vercel bot comment on this PR. Use the following table as an example template. | Site | Live | Preview | Search for | | -------------- | ------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------ | ----------------------------- | | WWW | [/blog/your-post](https://supabase.com/blog/your-post) | [/blog/your-post](https://zone-www-dot-com-git-branch-name-supabase.vercel.app/blog/your-post) | unique phrase from the change | | Docs | [/docs/guides/your-page](https://supabase.com/docs/guides/your-page) | [/docs/guides/your-page](https://docs-git-branch-name-supabase.vercel.app/docs/guides/your-page) | unique phrase from the change | | Studio | [/dashboard](https://supabase.com/dashboard) | [/dashboard](https://studio-git-branch-name-supabase.vercel.app/dashboard) | unique phrase from the change | | Design system | [/design-system](https://supabase.com/design-system) | [/design-system](https://design-system-git-branch-name-supabase.vercel.app/design-system) | unique phrase from the change | | UI library | [/library](https://supabase.com/library) | [/library](https://ui-library-git-branch-name-supabase.vercel.app/library) | unique phrase from the change | | Knowledge base | [/kb/guides/your-page](https://supabase.com/kb/guides/your-page) | [/kb/guides/your-page](https://kb-git-branch-name-supabase.vercel.app/kb/guides/your-page) | unique phrase from the change | --> <!-- ## Additional context Optionally add any other context or screenshots. --> ## Review instructions ## Checklist Check all before review: - [x] I have read [CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/CONTRIBUTING.md) - [x] If I wrote a new docs topic or edited an existing topic, I used the `/write-the-docs` or `/edit-the-docs` skill, which applies the docs [style guide](https://github.com/supabase/supabase/tree/master/apps/docs/style-guide) <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Updates** * OrioleDB is now labeled as being in public beta rather than public alpha, and project creation selects the beta release channel. * Restore-to-new-project and Point-in-Time Recovery notices clarify that these features are unavailable for OrioleDB projects. * OrioleDB projects now follow the standard eligibility checks and page flow for scheduled backups. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
Tanun Turbo Chalermsinsuwan
|
cd305313e4 |
fix(roles): Show only document-defined roles (#51087)
## Problem As part of having `None / No Access` available to customers, we need to start providing this role entry in `/platform/organization/:ref/roles` endpoint. However, when making it available, the role will show up prematurely on all the components that relies on `useOrganizationRolesV2Query` function. ## Solution This change is to allow us to test the behavior of the new role without having to turn the API on/off. The UI will show only the "predefined" entries and ignore the "extras" sent by API. After this is merged, we will do the following 1. Unhide the None role from the API https://github.com/supabase/platform/pull/39137 -- this will not have any effect on the frontend as we already ignore it in this PR 2. Work and continue testing on https://github.com/supabase/supabase/pull/50922 -- which will be easier to verify as we no longer need to change the API side ## Review instructions 1. Modify the items in the `FIXED_ROLE_ORDER` list, remove some roles from there 2. You will see that the role will disappear from the components like the invitation form or managed access form. ## Checklist Check all before review: - [x] I have read [CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/CONTRIBUTING.md) - [x] If I wrote a new docs topic or edited an existing topic, I used the `/write-the-docs` or `/edit-the-docs` skill, which applies the docs [style guide](https://github.com/supabase/supabase/tree/master/apps/docs/style-guide) <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit ## Summary by CodeRabbit * **Bug Fixes** * Organization role lists now show only supported roles, in the expected order. Roles outside the supported set are no longer displayed. This keeps the list consistent and focused on recognized roles, making available organization roles easier to review. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
Ivan Vasilov
|
ec6be68356 |
chore: Bump vulnerable deps (#50901)
This PR bumps the vulnerable dependencies `devalue`, `mermaid`, `@faker-js/faker`, `brace-expansion`, `undici`, `fast-uri` and `markdown-it`. It also dedupes `rolldown`, `vite` and various `react-router` deps. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Chores** * Updated development and build tooling for Lite Studio, Studio, and the Vue block, along with tooling used in automated Studio checks. These changes do not alter app features or workflows, and no new user-facing capabilities or behavior changes are included. They are limited to the project’s underlying development setup. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
Kamil Ogórek
|
c5b4fbfa11 |
fix: Handle NO_PROJECT_MARKER for projectRef (#51083)
Skip `NO_PROJECT_MARKER` values for projectRef in API validation. |
||
|
Danny White
|
92952bf903 |
fix(studio): clarify S3 access key dialogs (#51070)
## Problem The S3 access key creation dialogs are wider than their contents, use plural titles for one key pair, and call the name field “Description” even though the table calls it “Name”. The save state also implies both values disappear, although only the secret does. ## Solution Use the small dialog size for both states. Use singular titles, label the field “Name”, shorten the create button to “Create”, and clarify when the secret must be copied. The API field remains `description`. ## Review instructions 1. Open a project’s **Storage > S3** page and select **New access key**. Check the dialog width, title, Name field, and Create button. 2. Create a key and check the save dialog width, singular title, and secret visibility guidance. | Before | After | | --- | --- | | <img width="1084" height="572" alt="CleanShot 2026-09-30 at 14 37 20@2x" src="https://github.com/user-attachments/assets/781706ee-0ecc-4535-abb5-f6ac65f02c71" /> | <img width="844" height="584" alt="CleanShot 2026-09-30 at 14 36 56@2x" src="https://github.com/user-attachments/assets/119df19f-2f39-4e23-94b4-26665583765c" /> | | <img width="1096" height="730" alt="CleanShot 2026-09-30 at 14 37 57@2x" src="https://github.com/user-attachments/assets/00481ed7-dc05-48b9-8cbc-e76d608aa4b1" /> | <img width="842" height="780" alt="CleanShot 2026-09-30 at 14 37 39@2x" src="https://github.com/user-attachments/assets/8c837101-250a-474f-a0fc-cf46ce491f83" /> | <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Updates** * The credential form now labels the field “Name” and uses “Create” for the submit button. * Confirmation text now clarifies that the access key is bucket-wide, bypasses RLS, and its secret is shown only once. It also refers to a single access key instead of using S3-specific wording. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
Pamela Chia
|
38b74af3f1 |
fix(studio): fall back for framework icons without an asset (#51065)
I made the connected-project framework icons fall back when no shipped SVG exists for a framework. The three icon sites built `/img/icons/frameworks/<framework>.svg` straight from the integration's framework preset, which is an open-ended string. They only fell back when the value was empty, so any preset without an asset (`express`, `hono`, `fastapi`, `tanstack-start` and others) showed a broken image and logged a 404. **Changed:** - **Broken framework icons**: `getFrameworkIconUrl` returns the asset URL only for slugs in a set that mirrors `public/img/icons/frameworks/`. The integration connection row, the org project linker and the marketplace project picker now show their existing fallback icon for any other slug. A test keeps the set equal to the directory listing. - **Framework type**: I deleted the hand-kept `VercelFramework` union. It listed exactly the shipped icon slugs, while the API types the field as `string | null`, and that mismatch is what made the old empty-only check look safe. **Note:** I rejected an `onError` fallback because the browser still sends the 404 request. Adding logos for common presets is left for design. ## To test Tested on Vercel preview (staging): no real connection there uses these presets, so I rewrote the org integrations response in the browser to give one integration four connections. - [x] Open an org's Integrations page with connections whose framework has no shipped icon (`express`, `eve`, `tanstack-start-lovable`). Expect the fallback badge and no request under `/dashboard/img/icons/frameworks/` for those slugs. Observed: all three rows showed the badge and the network log had no request for their SVGs. - [x] Same page with a `nextjs` connection. Expect its framework logo. Observed: `nextjs.svg` loaded with a 200. - [x] Same page with the real, unmodified response (one connection with `framework: null`). Expect the badge, no frameworks requests, and no new console errors. Observed: as expected. ## Linear - fixes GROWTH-1309 <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Bug Fixes** * Vercel integration and project views now display framework icons when available and fall back to the Vercel icon when no matching icon exists. * Framework metadata now supports values beyond a fixed list, while unsupported frameworks continue to use the fallback icon. * **Tests** * Added coverage for supported and unsupported framework icons, including base-path handling. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
Pamela Chia
|
9690efeb42 |
fix(vault): link to current dashboard route (#51058)
I updated first-party Vault links to open the current secrets route directly. Wrapper credentials, extension metadata, and blog posts still linked to the retired path and relied on a redirect. ## To test On the preview: - [x] Inspect a Wrapper credential's Vault link. Expect `/integrations/vault/secrets` with a `search` query for that credential. - [x] Open the inspected target URL. Expect Vault to show the matching secret. - [ ] Click a Wrapper credential's Vault link. Expect the filtered Vault view. - [ ] Open the pgsodium extension's Vault link and a Vault blog link. Expect `/integrations/vault/secrets` without the retired route in the address bar. ## Linear - fixes GROWTH-1312 <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Updates** * Vault secrets links now direct you to the project’s Integrations page, including links from wrapper metadata, blog articles, and the `pgsodium` extension listing. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
Pamela Chia
|
e0e58f8814 |
fix(studio): redirect moved dashboard routes (#51056)
I added permanent redirects for the moved Dashboard routes that still send visitors to 404s. Project and organization identifiers carry through, while the old project billing path opens the organization picker for billing. **Note:** The bare `/dashboard/project` path redirects straight to Organizations instead of the `/dashboard/projects` hop named in GROWTH-1295, since `/projects` already redirects there. ## To test Tested on the Studio preview: - [x] Requested the eight old Dashboard paths in GROWTH-1295 while signed out. Each returned 308 with the specified destination. - [ ] Request bare `/dashboard/project` while signed out on the latest preview. Expect a single 308 to `/dashboard/organizations`. - [x] Requested a project backup path with a query string. The destination kept the project ref and query string. - [x] Requested `/dashboard/project/_`. The project picker remained reachable. ## Linear - fixes GROWTH-1295 <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Bug Fixes** * Added permanent redirects for legacy Studio routes covering account and project pages, backups, email templates, edge-function logs, secrets, and billing settings. * Redirects preserve incoming query parameters and URL fragments; the project selector remains unaffected. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
Danny White
|
68d5011514 |
fix(studio): hide secret visibility controls in pipeline edit forms (#51010)
## Problem Pipeline edit forms hide stored credentials but still show visibility controls beside their placeholders. The controls suggest that the stored secret can be revealed. ## Solution - Hide visibility controls in edit mode for ClickHouse, Snowflake, DuckLake, and Analytics Bucket secret fields. - Keep the controls available when creating a destination, with accessible labels for the DuckLake and Analytics Bucket controls. | Before | After | | --- | --- | | <img width="1024" height="196" alt="CleanShot 2026-09-29 at 16 48 56@2x" src="https://github.com/user-attachments/assets/a9da9a32-ab17-4c07-abf3-dfa88b8c6475" /> | <img width="1024" height="168" alt="CleanShot 2026-09-29 at 16 47 23@2x" src="https://github.com/user-attachments/assets/fddeb880-cd23-4752-ae73-8f27348c647f" /> | ## To test 1. Open **Database → Pipelines** and edit a destination of each type: ClickHouse, Snowflake, DuckLake with custom parameters, and Analytics Bucket. Check that the hidden secret fields have no eye button. 2. Start creating each destination and check that its secret fields still offer a working visibility control. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit ## Summary * **Improvements** * Secret fields in replication destination forms remain masked when editing an existing destination, and their visibility controls are hidden. When creating a destination, supported secret fields can be revealed. * **Accessibility** * Catalog-token visibility controls now use dynamic, descriptive labels. DuckLake catalog URL and S3 secret-key reveal controls also have descriptive labels. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
Danny White
|
6b7c91a773 |
docs(pipelines): clarify ClickHouse setup and form copy (#51009)
## Problem The ClickHouse destination guide leaves parts of resource setup unclear. The pipeline form suggests the `default` ClickHouse user and database even when a dedicated user and database are prepared. ## Solution - Clarify the ClickHouse setup path, connection details, engine choice, and query example in the guide. - Align the pipeline form's labels, examples, and help text with that setup path. - Include **Start pipeline** in the BigQuery guide before the cost confirmation and **Create and start pipeline**. ## Review instructions 1. Open **Database → Pipelines**, add a pipeline, and choose **ClickHouse**. Check the endpoint label, user and database examples, and table engine help. 2. Read the [ClickHouse destination guide](https://supabase.com/docs/guides/database/replication/pipelines/clickhouse), especially **Prepare ClickHouse resources** and **Configure ClickHouse as a destination**. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Documentation** * Updated the BigQuery guide to explain the pipeline validation, cost review, and start steps. * Expanded the ClickHouse guide with destination setup requirements, engine behavior, and querying guidance for current-state views and append-only history. * **User Experience** * Clarified ClickHouse connection field labels and descriptions, password visibility controls, and table-engine options in the setup form. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
Danny White
|
3b1867f314 |
fix(studio): use neutral fallbacks for pending destination marks (#51003)
## Problem Some Pipelines destinations should not display third-party brand marks until their use is confirmed. ## Solution Render neutral text monograms for destinations with pending brand marks. Keep approved destination marks unchanged and preserve the existing assets so they can be restored with a small configuration change. | After | | --- | | <img width="1022" height="936" alt="CleanShot 2026-09-29 at 11 44 37@2x" src="https://github.com/user-attachments/assets/d94fca61-aa02-4efb-aa78-47ada5d149d3" /> | ## Review instructions 1. Open `/project/<ref>/database/replication`. 2. Open the destination picker and confirm destinations with pending marks use neutral two-letter monograms. 3. Confirm the other destination marks are unchanged. ## Checklist - [x] I have read [CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/CONTRIBUTING.md) <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Style** * ClickHouse and Snowflake destinations now display “CH” and “SF” monograms instead of image marks. BigQuery and DuckLake continue to display their image marks, while destinations without configured branding continue to show their destination icons. These logo treatments make the configured destination branding visible in the replication destination interface. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
Danny White
|
d451bdc264 |
fix(studio): place pipeline arrows on horizontal edges (#50965)
## Problem In branched Pipelines diagrams, status chips sit on the shared vertical bend, making flow direction unclear. - Resolves [DEPR-689](https://linear.app/supabase/issue/DEPR-689/move-pipeline-arrows-to-horizontal-edge-segments) - Resolves duplicate [PIPE-1079](https://linear.app/supabase/issue/PIPE-1079/move-destination-chart-arrows-to-horizontal-edges) ## Solution Place each chip on its destination's final horizontal edge segment. Keep the single-destination chip centred on its straight edge. | 1× Destination (No Change) | | --- | | <img width="1352" height="678" alt="CleanShot 2026-09-29 at 14 03 22@2x" src="https://github.com/user-attachments/assets/c495318c-811b-4817-9b25-af32d12d8e08" /> | | _Before_ | | <img width="1350" height="682" alt="CleanShot 2026-09-29 at 14 02 37@2x" src="https://github.com/user-attachments/assets/da862b82-4605-48df-93cd-c035443acc9d" /> | | _After_ | | 2× Destinations | | --- | | <img width="1354" height="680" alt="CleanShot 2026-09-29 at 14 01 15@2x" src="https://github.com/user-attachments/assets/970aa562-1ab9-4ff1-90e0-3c0fe95d01dc" /> | | _Before_ | | <img width="1354" height="674" alt="CleanShot 2026-09-29 at 14 00 50@2x" src="https://github.com/user-attachments/assets/5501657b-32a2-485d-907f-8a0a8fae595d" /> | | _After_ | ## Review instructions 1. Open Database > Pipelines with one destination, then with several. Check the chip position and arrow direction at desktop and phone widths. ## Checklist - [x] I have read [CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/CONTRIBUTING.md) <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Bug Fixes** * Improved label placement in the database replication diagram when edges are shifted, making the connections easier to read. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
Danny White
|
e5dde899cd |
fix(studio): stabilise pipeline header loading (#50964)
## Problem The pipeline detail header shifts slightly as its loading placeholders become text. - Resolves [DEPR-683](https://linear.app/supabase/issue/DEPR-683/reduce-layout-shift-in-pipeline-header-loading-states) ## Solution Match the breadcrumb, title, status, and destination placeholders to their loaded line heights. ## Review instructions 1. Open a pipeline detail page and reload it. Check that the header height stays steady as its data arrives. ## Checklist - [x] I have read [CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/CONTRIBUTING.md) <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Style** * Increased the height of loading placeholders for replication pipeline status, breadcrumbs, page titles, and destination names. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
Danny White
|
ed692f6905 |
feat(select): schedule livestream banners (#51006)
## Problem The Select banners on www and Studio still promote attendance. They need to keep serving the waitlist until the event, promote the livestream during the requested window, and disappear after the event. ## Solution Use a shared three-phase clock: existing promotion before 8:00am PT on 2 October, livestream promotion from 8:00am to 5:30pm PT, and no banner afterwards. Both livestream CTAs lead to `select.supabase.com`, where viewers can choose a stage. Separate dismissal keys let someone who dismissed the earlier promotion see the livestream. Open pages set a timer for the next boundary and recheck on visibility, focus, or page restore. | `www` | | --- | | <img width="736" height="136" alt="CleanShot 2026-09-29 at 16 27 38@2x" src="https://github.com/user-attachments/assets/1281bcf0-ece4-41fc-99d2-1f9ab6e1b3f5" /> | | _Until Friday 8am PT_ | | <img width="734" height="138" alt="CleanShot 2026-09-29 at 16 28 06@2x" src="https://github.com/user-attachments/assets/05b8779a-9961-4886-ad7d-96ba31c8b4f7" /> | | _Friday 8am to 5:30pm PT_ | | `studio` | | --- | | <img width="612" height="454" alt="CleanShot 2026-09-29 at 16 26 51@2x" src="https://github.com/user-attachments/assets/0d9a8bbb-c636-41dc-aa76-381196c149c2" /> | | _Until Friday 8am PT_ | | <img width="616" height="440" alt="CleanShot 2026-09-29 at 16 27 09@2x" src="https://github.com/user-attachments/assets/458afdb9-6576-4699-9419-947ca5312bcd" /> | | _Friday 8am to 5:30pm PT_ | ## Review instructions 1. Open the [www homepage](https://zone-www-dot-com-git-dnywh-select-2026-livestre-93dab1-supabase.vercel.app/) and a [hosted Studio dashboard](https://studio-staging-git-dnywh-select-2026-livestream-05b822-supabase.vercel.app/) in separate tabs. If the Privacy Policy update card is in front in Studio, close it (only) to reveal the Select banner. 2. In each tab's DevTools console, paste this helper: ```js window.selectRealNow = Date.now window.showSelectAt = (iso) => { Date.now = () => new Date(iso).getTime() window.dispatchEvent(new Event('focus')) } ``` 3. Run `showSelectAt('2026-10-02T07:59:00-07:00')`: both banners keep the existing “Apply to attend” CTA. 4. Run `showSelectAt('2026-10-02T08:00:00-07:00')`: www shows “Supabase Select 2026” and “Watch the livestream”; Studio shows the same title, the description “Keynote, main stage, and build stage, streamed all day.” and “Watch livestream”. Both CTAs link to `https://select.supabase.com/`. 5. Run `showSelectAt('2026-10-02T17:30:00-07:00')`: neither banner is visible. Restore the clock with `Date.now = window.selectRealNow; window.dispatchEvent(new Event('focus'))`. The console clock override affects only the current tab and is lost on reload. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit - **New Features** - The Select 2026 banner switches from waitlist messaging to livestream details and a “Watch livestream” link during the livestream period. - Livestream banner dismissals are tracked separately from waitlist banner dismissals. - Promotion banners end at 5:30 p.m. Pacific on October 2, 2026, and update when the promotion changes phase, including after returning to an open tab. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
Charis
|
0daafca2ca |
feat(studio): status page banner (incident / maintenance / upcoming) (#51044)
## Summary * Adds a new global status banner (`StatusBanner`) driven by the [incident.io](<http://incident.io>) status page data, showing at most one of: an active incident, in-progress maintenance, or upcoming maintenance, in that priority order. * All three types are independently dismissible (persisted to a new localStorage key, `status-banner-dismissed-keys`); dismissal hides the banner for items still active, and a new incident reappears even if a related item was previously dismissed. * Only shows to users who are actually affected (based on their projects' regions) or when region data is incomplete (fails open), and is bypassed entirely by the existing emergency incident override. * Behind the existing `incidentIoStatusPage` ConfigCat flag — `AppBannerWrapper` renders this new banner instead of the legacy `StatusPageBanner` only when the flag is on; default behavior is unchanged. * This is PR 5b in a stacked series for Linear [FE-4057](https://linear.app/supabase/issue/FE-4057) — see that issue for full design context. ## Test plan * New unit tests (`StatusBanner.utils.test.ts`) covering banner-selection priority, dismissal-key handling, and copy generation * New MSW component test (`StatusBanner.test.tsx`) covering loading state, dismiss-and-persist, and the emergency-override path * `pnpm --filter studio run typecheck`, `lint:ratchet`, `pnpm knip --workspace apps/studio`, `pnpm test:prettier`, and relevant vitest suites all pass 🤖 Generated with [Claude Code](<https://claude.com/claude-code>) Co-Authored-By: Claude [noreply@anthropic.com](<mailto:noreply@anthropic.com>) <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Added status banners for relevant incidents and scheduled maintenance, including incident details, maintenance timing, and links to the status page. * Banners can be dismissed, and dismissed items stay hidden while new incidents or maintenance updates can still appear. * Upcoming maintenance banners appear within the relevant lead time, and maintenance timing is shown when available. * Emergency overrides display a warning banner without a dismiss option. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
Charis
|
d22702e907 |
refactor(studio): extract user project regions + emergency override hooks (#51033)
## Summary - Extracts `useUserProjectRegions` (org + project region aggregation, fail-open on fetch errors) and `useEmergencyIncidentOverride` (the `ongoingIncident` flag / env var check) out of `useStatusPageBannerVisibility`, so the upcoming incident.io status-page banner can reuse both without duplicating the org/project fan-out logic. - No behavior change for the legacy banner except one intentional fix: `StatusPageBanner.utils.ts` compared the incident's affected regions (lowercased) against the user's regions (not normalized), so a mixed-case region on either side could silently fail to match. Both sides now go through the same `normalizeRegion` helper. - Part of the Linear FE-4057 stack (PR 5a of 6). Base branch is PR 4 (`charis/fe-4057-pr4-project-creation-status-admonition`), not master. Linear: FE-4057 ## Test plan - [x] `pnpm --filter studio run typecheck` - [x] `pnpm --filter studio run lint:ratchet` - [x] `pnpm knip --workspace apps/studio` - [x] `pnpm test:prettier` - [x] `pnpm --filter studio exec vitest run` on the touched test files and the `hooks/misc/` and `components/layouts/AppLayout/` directories (all passing, no regressions) <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Bug Fixes** * Improved status banner targeting by matching incidents against normalized regions across the user’s projects. * Updated banner visibility checks to handle incomplete project or region data, including when project information fails to load. * Improved loading behavior so the banner can be evaluated based on user-region data rather than waiting for separate organization and project requests. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
Charis
|
53b20cad5e |
feat(studio): project creation status admonition (#51029)
## Summary - Adds a new project-creation-form incident warning path behind the `incidentIoStatusPage` ConfigCat flag (default off — no visible behavior change until the flag is enabled) - When the flag is on, reads the new `/api/status-page` endpoint (added earlier in this stack) instead of the legacy `/api/incident-status` endpoint, and only fetches the legacy endpoint when the flag is off - Extracts region-matching logic into `RegionSelector.utils.ts` (`regionMatches`, `getItemsAffectingProjectCreation`) with unit test coverage See Linear FE-4057 for full context and design. ## Test plan - [x] `pnpm --filter studio run typecheck` - [x] `pnpm --filter studio run lint:ratchet` - [x] `pnpm knip --workspace apps/studio` - [x] `pnpm test:prettier` - [x] `pnpm --filter studio exec vitest run components/interfaces/ProjectCreation/RegionSelector.utils.test.ts` (35/35 passing) <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Project creation displays a warning and links to the status page when an incident or maintenance event may affect the selected region. * Status notices match exact regions and broader smart-region groupings; global project-creation notices are also shown. * The AI assistant can report visible, active incidents and in-progress maintenance, including affected components and update details. When there are no active events, it reports that status. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
Pamela ChiaandJoshen Lim
|
4a941518e3 |
feat(studio): track Explorer runs and saves (#51004)
I added outcome events for Explorer query runs and successful manual notebook saves. Existing page visits and preview toggles do not show whether users complete queries or persist notebooks. **Changed:** - **Query usage:** Accepted runs from query tabs and notebook cells emit submitted and terminal outcome events with a shared run ID. Canceled confirmations emit no run events. - **Notebook adoption:** Successful manual saves emit created or updated events. Recreated notebooks count as creations. Unsaved drafts and failed saves emit neither. - **Event metadata:** Explorer action events use `Explorer` as their page title. **Note:** Assistant-generated saves are outside this PR. Custom properties omit SQL and notebook content. Page visits still carry the browser title, which can include a notebook name. ## To test Tested on the staging preview: - [x] Run valid and invalid SQL from an Explorer query tab. Each run emits one submitted event and one matching completed or failed event with the same run ID. - [x] Run database and Logs notebook query cells, then add a markdown cell. The query cells emit matching event pairs; the markdown cell emits no query event. - [x] Save a new notebook, then edit and save it again. The successful saves emit created and updated events. - [x] Cancel a guarded query. It emits no query run event. - [ ] Recreate a notebook deleted on the server after local edits. A successful save emits created, not updated. - [x] Inspect an Explorer action event request. Its page title is `Explorer`; page visits still use the browser title. - [ ] Force a notebook save failure. It should emit no save event. This case was not tested manually. ## Linear - fixes GROWTH-1298 <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Analytics** * Explorer query runs are tracked for database and log queries, including whether they complete or fail. * Query activity is associated with its location in Explorer, such as a query tab or notebook cell. * Successful notebook saves are tracked as creations or updates. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Joshen Lim <joshenlimek@gmail.com> |
||
|
Charis
|
13de8189c9 |
feat(studio): assistant get_active_incidents on status page endpoint (#50994)
## Summary * Adds a second branch to the assistant's `get_active_incidents` tool (`apps/studio/lib/ai/tools/incident-tools.ts`) that reads `/api/status-page` when the global ConfigCat flag `incidentIoStatusPage` is on, instead of the legacy `/api/incident-status` endpoint. * Filters on `visible`, ignores `show_banner` (only the global banner respects it), and concatenates ongoing incidents + in-progress maintenances (not scheduled maintenances). * Adds `isServerFlagEnabled` to `lib/server/configcat.ts` for reading global, non-user-targeted ConfigCat flags server-side, and threads the flag through `getTools` from `pages/api/ai/sql/generate-v4.ts`. This is PR 3 of 6 in the [FE-4057](https://linear.app/supabase/issue/FE-4057/frontend-bannerbot-reconfigured) stack — stacked on `charis/fe-4057-pr2-support-form`. Behind the `incidentIoStatusPage` flag (default off), so this ships no user-visible change on its own. See Linear [FE-4057](https://linear.app/supabase/issue/FE-4057/frontend-bannerbot-reconfigured) for full context. ## Test plan - [X] `pnpm --filter studio run typecheck` - [X] `pnpm --filter studio run lint:ratchet` - [X] `pnpm knip --workspace apps/studio` - [X] `pnpm test:prettier` - [X] `pnpm --filter studio exec vitest run lib/ai/tools/incident-tools.test.ts` (19/19 passing, including 7 new tests for the status-page branch) |
||
|
Alaister YoungandAlaister Young
|
995f6f65c7 |
[FE-4483] fix(studio): disable network bans for v3 projects (#50997)
Disables network bans for v3 (`AWS_K8S`) projects and shows a specific unsupported notice. The shared banned-IP query waits for project details and skips unsupported projects, covering both Database Settings and Advisor for v3 and High Availability projects. The hook returns the standard query result and uses `skipToken` to prevent unsupported requests, including manual refetches. Database Settings handles project-detail errors at the call site. Open unban confirmations are cleared when the section becomes disabled, and submission checks eligibility. Addresses [FE-4483](https://linear.app/supabase/issue/FE-4483/disable-network-bans-for-v3-aws-k8s-projects). ## To test - Open Database Settings on a v3 project. Check that Network bans shows the v3 notice, hides the IP list and unban controls, and makes no network-bans retrieval request on initial load or reload, including while Advisor is mounted. - Check that an HA project still shows its existing notice and makes no network-bans retrieval request on initial load or reload. - Navigate from a supported project to a v3 or HA project and check that no banned-IP request is sent for the unsupported project and no banned-IP signals from the previous project appear in Advisor. - If project details fail without cached data, check that Network bans shows an error after retries finish and does not retrieve bans. A successful retry should restore normal behavior. - Open an unban confirmation on a supported project, then navigate to a v3 or HA project. Check that the dialog closes without sending an unban request and stays closed when returning. A newly opened confirmation should still work. - On a supported project, check the empty state and banned IP list. Confirm that users with permission can unban an IP and users without permission see a disabled button with the permissions tooltip. Validation: 17 focused tests passed, covering automatic and manual request suppression, project-detail error display and recovery, and navigation between supported and unsupported projects. Changed-file ESLint, Prettier, and full Studio typecheck (without the incremental cache) passed. Earlier local browser checks on `9912c6c` confirmed no retrieval requests for an HA project on AWS_K8S across reloads and Advisor, and a successful empty state on a supported project. The local failed-project case redirected to the organization after retries, so the inline error remains verified by the component test only. The latest preview, standalone v3 notice, populated bans/unban, and no-permission tooltip still need browser verification. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Bug Fixes** * Banned IP settings now show an unsupported-project notice for AWS Kubernetes projects and hide ban lists and unban actions for AWS Kubernetes and High Availability projects. * Banned IP data loads only after project details are available and only for supported projects; unsupported projects do not display cached ban data. * Project-detail errors are shown separately from ban-list errors. * Unban confirmations close when a project becomes unsupported or an unban succeeds. Unbanning is unavailable when you lack update permission or the project is unsupported. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Alaister Young <10985857+alaister@users.noreply.github.com> |
||
|
Manan GuptaandJoshen Lim
|
6a0518dd86 |
fix(studio): forward HA flag to project-creation pre-flight checks (#50902)
## Summary - Fixes MUL-1678: toggling High Availability on in the project-creation wizard 400'd for orgs that are HA-entitled but not enrolled in the "V3 rollout ramp" feature flag on the backend, because two pre-flight endpoints Studio calls before project creation didn't know about HA and hit the ramp check the real create-project call already bypasses. - Threads `highAvailability` through `useOrganizationAvailableRegionsQuery` (`GET /platform/projects/available-regions`, sent as `high_availability=true|false` on the query string) and `useProjectCreationPostgresVersionsQuery` / `useAvailableOrioleImageVersion` (`POST /platform/organizations/:slug/available-versions`, sent as `high_availability` in the body), including their query-key cache keys so HA and non-HA responses for the same org/provider/size don't collide. - Wires the (already form-tracked) `highAvailability` value into every call site: `ProjectCreationForm.tsx`, `RegionSelector.tsx`, and a new `highAvailability` prop on `PostgresVersionSelector.tsx` passed from `InternalOnlyConfiguration.tsx`. ## Problem The project-creation wizard's HA toggle is wired into the actual project-create request, but two pre-flight calls Studio makes before that (available regions, available Postgres versions) had no way to signal HA, so the backend's ramp-flag gate rejected them for HA-entitled orgs outside the ramp. ## Solution Add an optional `highAvailability` field end-to-end on the Studio side: query hook variables, cache keys, request serialization, and the components that already track the toggle via `useWatch`. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Bug Fixes** * Available regions and database versions in project creation now reflect the selected high-availability setting. * The Create button remains disabled while available regions are loading. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Signed-off-by: GuptaManan100 <guptamanan100@gmail.com> Co-authored-by: Joshen Lim <joshenlimek@gmail.com> |
||
|
Joshen Lim
|
fea8b8b41d |
Update copy RE disk configuration changes and cooldown (#50844)
## Context Reverts copy changes from the following PRs: - Docs: https://github.com/supabase/supabase/pull/42184 - FE: https://github.com/supabase/supabase/pull/47646 Our platform's disk management configuration limitation still follows the 4 hour cooldown at the moment, doesn't align with AWS's 4 changes in 24 hours rule just yet. This is just to prevent any confusion for now, and we'll need to update the copy again once behaviour matches AWS on our BE <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Updates** * Disk changes are now subject to an approximately four-hour cooldown after each modification, replacing the previous limit of four changes in a rolling 24-hour period. * Disk management screens now show the cooldown status, remaining wait time, and next available update time. * Updated platform guides and troubleshooting instructions to reflect the cooldown and explain available recovery options. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
Gildas Garcia
|
529e4a5366 |
Hide Postgres upgrade for v3 projects (#51024)
## Problem v3 projects do not support postgres upgrade but the option may appear. ## Solution Hide the Postgres upgrade for v3 projects <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Bug Fixes** * Projects running on AWS Kubernetes no longer display database upgrade alerts or read-replica warnings in service version settings. Other upgrade eligibility and warning conditions remain unchanged. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
Joshen Lim
|
b1b2cf3e6b |
Update checks for showing ipv4 callout (#51018)
## Context Updates checks for showing IPv4 add on callouts, should only be visible if the project's provider is AWS Involves updating 3 files: - `ConnectionPooling.tsx` - adds check for cloud provider + enabled features - `ConnectStepsSection.tsx` - adds check for cloud provider + enabled features - `Ipv4StatusPanel.tsx` - realised this is dead code, so deleted <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Updates** * IPv4 add-on notices in connection setup and connection pooling appear only for AWS projects with IPv4 enabled, when the existing connection and configuration requirements are met. * **Removals** * The standalone IPv4 status panel has been removed from the connection setup flow. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
Charis
|
5573d0dfbc |
fix(studio): disable network restrictions for v3 (AWS_K8S) projects (#50996)
## Summary - Network restrictions aren't supported on v3 (AWS_K8S) projects, but the Network Restrictions settings section previously only disabled itself for High Availability projects, leaving a fully working (but non-functional) UI for non-HA v3 projects. - Adds `useIsAwsK8sCloudProvider()` to the section's disabled check, alongside a v3-specific disabled notice mirroring the existing High Availability disabled notice pattern. Resolves [FE-4482](https://linear.app/supabase/issue/FE-4482/disable-network-restrictions-for-v3-aws-k8s-projects). ## Test plan - [x] `tsc --noEmit` passes for the changed file - [x] `eslint` passes for the changed file - [x] `prettier --check` passes for the changed file - [x] Mirrors the existing, already-shipped High Availability disabled-section pattern in the same component 🤖 Generated with [Claude Code](https://claude.com/claude-code) <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Behavior Changes** * Network restrictions are unavailable for AWS Kubernetes and High Availability projects, and for users without update permission. AWS Kubernetes projects display a dedicated explanation; restriction details and management controls are hidden. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
Manan Gupta
|
951a22183a |
feat: regenerate api types from production (#51019)
## Summary
- Regenerates `packages/api-types/types/{api-v2,platform}.d.ts` from the
live production OpenAPI specs (via the new `pnpm --filter=api-types run
codegen:prod`), picking up everything that's shipped to production since
the committed types were last regenerated.
- Notably includes `high_availability` on the `available-regions` and
`available-versions` project-creation pre-flight endpoints, which
unblocks the Studio-side wiring in #50902.
- Fixes one collateral typecheck break the regen surfaces: the invoice
schema's `prepaid_credits_applied_cents` field became required, and
`InvoicesSettings.test.tsx`'s mock invoice builder didn't set it.
## Description
`api-v1.d.ts` needed no changes — it was already in sync with
production. `api-v2.d.ts` and `platform.d.ts` pick up unrelated drift
that has landed on production independently of this change (a few new
fields/endpoints), verified against `pnpm api:verify-types` passing
clean and `pnpm typecheck` passing across the whole monorepo.
This PR is intentionally separate from #50902 (the Studio-side High
Availability pre-flight fix) so that PR's diff stays focused on the
actual feature work. #50902 will be rebased once this merges.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Tests**
* Updated the invoice test fixture to default prepaid credits applied to
zero.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Signed-off-by: GuptaManan100 <guptamanan100@gmail.com>
|
||
|
Charis
|
8b8569bd1a |
feat(studio): status page client data layer + support form (#50984)
## Summary * Adds the client query layer for `/api/status-page` (`statusPageQueryOptions` in `data/platform/status-page-query.ts`) and a shared normalization module (`lib/status-page/status-page.utils.ts`) that maps the endpoint response into region- and project-creation-aware `StatusItem`s — later PRs in this stack (assistant tool, project-creation admonition, global banner) build on this same module. * Wires the support form's status pill and incident admonition to the new data behind the `incidentIoStatusPage` ConfigCat flag. `useSupportStatus` branches between the new endpoint and the existing `useIncidentStatusQuery`/`processIncidentData` path, both mapped to the same `SupportStatus` shape. * `IncidentAdmonition` becomes purely presentational; the status link now points at the `pageUrl` returned by the endpoint instead of a hardcoded URL. Part of [FE-4057](https://linear.app/supabase/issue/FE-4057/frontend-bannerbot-reconfigured) — see Linear for full design context. ## Test plan - [X] `pnpm --filter studio run typecheck` - [X] `pnpm --filter studio run lint:ratchet` - [X] `pnpm knip --workspace apps/studio` - [X] `pnpm test:prettier` - [X] `pnpm --filter studio exec vitest run` (touched files) — 70 tests passing, including a flag-on case for `SupportFormPage` <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Support pages now display current incident and maintenance information, including relevant status descriptions and links to the status page. * Status details can reflect items affecting a user’s region or project-creation services. Upcoming maintenance is excluded from active alerts. * **Bug Fixes** * Status labels and alerts now account for loading, errors, incidents, and maintenance consistently across support pages. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
Joshen Lim
|
9aae037dff |
Joshenlim/fe 4475 fdw update sql to run proper alter statements instead of (#50988)
## Context Currently for FDWs under integrations, editing an FDW involves tearing it down then re-creating it - which while conveniently works has a lot of problems like: - Blast radius is way bigger than the edit - Everything is recreated, including vault secrets - Silent drops grants/comments/ownership - Cascades on dependent objects - Views or functions built on top of foreign tables would get dropped along with it Changes in this PR hence updates `getUpdateFDWSql` to diff the current wrapper state against the form state and generate targeted `ALTER` statements for only what actually changed ## To test - [ ] Verify that updating an existing wrapper still works as expected <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Wrapper changes can be saved in place, including server options, encrypted values, foreign tables, and column definitions. * Input fields can display placeholder text, and missing server-option values display their defaults. * **Improvements** * Saving is unavailable until encrypted values are ready; a waiting message appears while they load. * The edit panel closes after a successful save. Confirmation text explains that table or column changes may affect dependent functionality. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
Joshen Lim
|
e3fec137fe |
Joshenlim/fe 4466 audit logs update organization logs as well (#50935)
## Context Follows up from [this PR](https://github.com/supabase/supabase/pull/50799) - updates the Audit Logs UI for organization audit logs. Just differs from Account audit logs slightly with added "Actor" + "Target" column Reuses the same UI components from account audit logs so quite a bit of code clean up 🙂 <img width="1451" height="955" alt="image" src="https://github.com/user-attachments/assets/a1002cee-917f-4d9a-b977-3fab8ecd2d13" /> <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Organization audit logs now use a sortable table with row selection and a resizable details panel. * Actor details show a member’s username when available, otherwise the actor’s email; a dash appears when neither is available. * Logs can be filtered by users and projects, with separate messages for no logs and no matching results. * A refresh control and loading indicators help show audit-log updates. * **Bug Fixes** * Organization project lists stop loading when pagination totals are unavailable. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
Joshen Lim
|
93a262d185 |
Check region selection for project creation (#51012)
## Context Previously added telemetry for `selectedRegionOption` and `selectedRegionOptionType` [here](https://github.com/supabase/supabase/issues/50851) if the best available region option is available for users Opting to extend this telemetry (still just for Free plan orgs) irregardless if best available region was selected and include `initialRecommendedRegion` Main thing to understand is what regions users are spinning projects up in outside of the recommended option ## To test - [ ] Verify the telemetry network request after creating projects - [ ] Non-free plan: Telemetry request doesn't have `initialRecommendedRegion` in the payload - [ ] Free plan: Telemetry request has `initialRecommendedRegion` in the payload - Sends correctly if best available region option is available (default behaviour for staging) - Sends correctly if best available region option is NOT available (override with dev tools the configcat flag) |
||
|
Jordi Enric
|
8f6a6f7032 |
fix(studio): wait for organization before loading regions (#50572)
## Problem The new-project page can request available regions with a paid compute size before the selected organization plan resolves. For free organizations, this produces a failed request followed by a successful request without the size. ## Fix Delay both available-regions query observers until the selected organization resolves, while preserving size-dependent refetches. Add request-level coverage for the initial free- and paid-plan behavior. ## How to test - Run `pnpm --filter studio exec vitest --run 'tests/pages/new/[slug].test.tsx'`. - Open the new-project page for a free organization and inspect the available-regions request. - Expected result: one initial request is sent without `desired_instance_size`; paid organizations send one initial request with `desired_instance_size=micro`. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit - **Bug Fixes** - Improved project creation so available regions are loaded only after an organization is selected. - Ensured region availability requests use the appropriate instance size for the organization’s plan: no size parameter for free plans and `micro` for paid plans. - Prevented unnecessary region-availability requests when no organization has been selected. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
Pamela Chia
|
138b654994 |
fix(studio): point Usage log ingest and query links at logs-* docs (#51001)
## Problem The org Usage page links added in #50570 point to `/docs/guides/platform/manage-your-usage/log-ingest` and `/log-query`. Neither page exists. The docs live at `logs-ingest` and `logs-query`, so every click from the Usage page lands on a 404. Within a day of #50570 shipping, these two paths were the top docs 404s by unique visitors. ## Solution - Point both Usage page links at the `logs-*` pages. - Add permanent redirects from the singular paths, because they're already being shared: search engines and AI assistants now send people to them. The existing generator in `apps/www/next.config.mjs` adds the `.md` variants. ## To test On the Vercel previews: - [x] Open an org's Usage page on the Studio preview and click the Log Ingestion docs link: expect the `logs-ingest` docs page, not a 404. Opens `supabase.com/docs/guides/platform/manage-your-usage/logs-ingest` in a new tab ("Manage Logs Ingest usage"). - [x] Click the Log Query docs link: expect the `logs-query` docs page. Opens `.../logs-query` in a new tab ("Manage Logs Query usage"). - [x] No docs link on the Usage page still points at the singular `log-ingest` or `log-query` paths. - [x] On the www preview, request `/docs/guides/platform/manage-your-usage/log-ingest` and `/log-query`: expect a 308 to the `logs-*` pages. Both return 308 to the matching `logs-*` path. The www preview doesn't serve `/docs`, so I confirmed both targets return 200 on production. - [x] `log-ingest.md` and `log-query.md` also return 308 to the matching `logs-*.md` paths. ## Linear - fixes GROWTH-1296 <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Bug Fixes** * Updated the Log Ingestion and Log Query documentation links to their current pages. * Added permanent redirects from the previous documentation paths to the corresponding pages. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
Danny White
|
5951fb6c47 |
fix(studio): polish Pipelines loading and update cues (#50963)
## Problem Pipelines loading causes layout shifts, and the update cue is hard to connect to its menu action. - Resolves [PIPE-1078](https://linear.app/supabase/issue/PIPE-1078/show-destination-rows-while-details-are-loading) - Resolves [DEPR-688](https://linear.app/supabase/issue/DEPR-688/widen-the-update-available-modal) - Resolves [DEPR-691](https://linear.app/supabase/issue/DEPR-691/clarify-the-update-available-indicator-in-pipeline-actions) ## Solution Reserve space for the graph and list while loading, show destination rows before their details arrive, align the detail header, and stack version values in the update dialog. Match the primary-colour dot on the options button and its Update available menu item. Give the status tooltip more room. | Before | After | | --- | --- | | <img width="408" height="346" alt="8294" src="https://github.com/user-attachments/assets/9a44dfe0-5473-4809-b705-fd6077efe44b" /> | <img width="844" height="738" alt="CleanShot 2026-09-28 at 17 10 34@2x" src="https://github.com/user-attachments/assets/4eba3f16-6dc4-4c02-83b4-9689203859bd" /> | | After | | --- | | <img width="426" height="472" alt="CleanShot 2026-09-28 at 17 11 27@2x" src="https://github.com/user-attachments/assets/8b3c181c-b48e-4803-a24a-fb7dce3957d4" /> | | _Links ambiguous dot to dropdown menu item_ | | <img width="1942" height="262" alt="CleanShot 2026-09-28 at 17 29 18@2x" src="https://github.com/user-attachments/assets/efc047bb-a8ea-4041-bd0d-fa2cb15f4414" /> | | _Better alignment with nav bar above it_ | ## Review instructions 1. Reload Database > Pipelines and check the loading layout and destination rows. 2. Open a pipeline detail page and check its header, update dialog, and matching update dots. ## Checklist - [x] I have read [CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/CONTRIBUTING.md) <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Bug Fixes** * Destination rows now appear while pipeline details are loading, with controls becoming available when the details finish loading. * **Style** * Loading states on the replication page now use diagram and table-shaped placeholders. * Updated replication page spacing, version-status tooltips, update indicators, and the version comparison layout. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
Danny White
|
c415f502ed |
feat(studio): show publication partition handling (#50773)
## Problem During pipeline creation, Studio did not show how an existing Postgres publication handles partitioned tables. The checkbox in the new-publication sheet also made the two possible modes harder to compare. Resolves [DEPR-675](https://linear.app/supabase/issue/DEPR-675/show-and-edit-postgres-partition-handling-for-publications). ## Solution Replace the checkbox in the new-publication sheet with a two-option dropdown. The default remains “Use parent table identity”. For an existing publication, append its partition-handling mode to the Publication field description in the pipeline creation sheet. This shows the current setting without presenting it as an editable pipeline option. Changing an existing publication’s setting is outside this PR. | Existing Publication Selection | | --- | | <img width="1260" height="224" alt="CleanShot 2026-09-28 at 12 52 10@2x" src="https://github.com/user-attachments/assets/240d7c23-d226-40b9-8d27-a359c8ae4b75" /> | | _Loading_ | | <img width="1238" height="198" alt="CleanShot 2026-09-28 at 12 52 00@2x" src="https://github.com/user-attachments/assets/36c8b1de-eb47-4f76-890d-19d0f33a75a1" /> | | _One of two values_ | | New Publication Creation | | --- | | <img width="832" height="660" alt="CleanShot 2026-09-28 at 12 52 33@2x" src="https://github.com/user-attachments/assets/c1108c3a-d65b-4d20-b1a8-7e0b68fe5e87" /> | | _One of two values_ | | <img width="840" height="650" alt="CleanShot 2026-09-28 at 12 52 40@2x" src="https://github.com/user-attachments/assets/6a2c23d9-12d5-4949-91b1-3867b60ccdd5" /> | | _Second of two values_ | ## Review instructions 1. Open the pipeline creation sheet and choose to create a new publication. Confirm that Postgres partition handling offers “Use parent table identity” and “Replicate each partition separately”, with the former selected by default. 2. Select each option in turn and confirm that the new publication is created with the selected mode. 3. Select an existing publication and confirm that its partition-handling mode appears in the description beneath Publication. Switch publications and confirm that the description updates. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * The replication destination form explains whether the selected publication uses the parent table’s identity or replicates partitions separately. It also shows when publication details are loading or unavailable. * When creating a publication, choose how partitioned tables are handled: use the parent table’s identity or replicate each partition separately. * **Tests** * Added coverage for publication guidance, loading and unavailable states, and partition-handling choices. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
Dongha
|
2c5b0a5ca0 |
fix(ui): fall back to writeText when clipboard.write fails (#50777)
## Problem Safari can expose `navigator.clipboard.write()` while rejecting it with `NotAllowedError`. Studio's shared clipboard helper treated that rejection as a terminal failure, so Copy buttons showed "Unable to copy to clipboard" even though `writeText()` worked. Fixes #50769 ## Solution - Fall back to `navigator.clipboard.writeText()` when the rich clipboard write fails. - Preserve the existing success callback and error behavior. - Add regression coverage for fallback success, total failure, and callback exceptions. ## Verification - `pnpm exec vitest run lib/helpers.test.ts --pool=threads` - `pnpm test:prettier` - `pnpm --filter ui run typecheck` - `pnpm --filter studio run typecheck` - `pnpm --filter studio run lint` - `npm run build -- --filter=studio` - Rendered browser verification with `clipboard.write()` forced to reject; `writeText()` received the expected payload and the Copy button showed success. ## Review instructions 1. Review the fallback logic in `packages/ui/src/lib/utils/clipboard.ts`. 2. Review the regression tests in `apps/studio/lib/helpers.test.ts`. 3. Confirm no generated or vendored files are changed. - [x] I have read CONTRIBUTING.md - [x] This PR does not change documentation content. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Bug Fixes** * Copying now falls back to standard clipboard copying when rich clipboard access is unavailable or denied. * An error message is shown only when both clipboard methods fail. Successful rich clipboard writes do not trigger a fallback if a follow-up action fails. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
Joshen Lim
|
dd02e96a17 |
Use common shift click helper for audit logs (#50894)
## Context This [PR](https://github.com/supabase/supabase/pull/50462) introduced a shared helper to handle shift click selections for tables. Changes here just updates the account audit logs to use that shared helper <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Updates** * Audit log row selection now toggles individual rows on click and uses the last-clicked row as the anchor for Shift-click range selection. When no rows remain selected, the range anchor is cleared. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
Matt Rossman
|
e3a937edb0 |
chore(studio): pin online scorer threads to the built-in preprocessor (#50981)
Pins the online scorers' `trace.getThread()` to the built-in `thread` preprocessor, so we can set the Assistant project's default preprocessor to a [custom one for Topics](https://linear.app/supabase/issue/AI-1258/add-a-topics-preprocessor-that-caps-tool-results-in-assistant-traces) without changing scorer input. `getThread()` otherwise [uses the project default](https://github.com/braintrustdata/braintrust-sdk-javascript/blob/cc165a4843805b531645ddb1d27969204aab9ade/js/src/trace.ts#L807). Ref AI-1258 <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Bug Fixes** * Corrected thread retrieval to use Braintrust’s thread preprocessor, ensuring evaluation traces are processed consistently. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
CharisandClaude Code
|
b2cf3693dd |
feat(studio): /api/status-page endpoint backed by incident.io Widget API (#50931)
## Summary * Adds `/api/status-page` (Next route + TanStack wrapper), backed by the [incident.io](<http://incident.io>) Widget API, annotating each item with `visible`, `show_banner`, and (for scheduled maintenances) `banner_lead_days`. * Deployment-mode visibility is driven by a new `status_page:visibility_field_ids` custom-content key. * Widget array parsing is fault-tolerant: a malformed item in one array is dropped and logged rather than failing the whole response, so one bad item can't hide a real ongoing incident. * 429s from [incident.io](<http://incident.io>) are retried with equal-jitter exponential backoff, respecting `Retry-After`, up to 2 retries. * Nothing consumes this endpoint yet — it replaces no existing behavior and changes nothing user-visible. Later PRs (this is PR 1 of a stack) wire up consumers behind the `incidentIoStatusPage` ConfigCat flag. Part of [FE-4057](https://linear.app/supabase/issue/FE-4057/frontend-bannerbot-reconfigured) — see Linear for full design context. ## Test plan - [X] `pnpm --filter studio run typecheck` - [X] `pnpm --filter studio run lint:ratchet` - [X] `pnpm knip --workspace apps/studio` - [X] `pnpm test:prettier` - [X] `pnpm --filter studio exec vitest run status-page` — 44 tests passing, including a regression test built from a real production [incident.io](<http://incident.io>) payload that initially failed to parse, and a compile-time type-safety regression test for the array-parsing helper Co-authored-by: Claude Code [charis@supabase.io](<mailto:charis@supabase.io>) <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Added a status page that displays ongoing incidents and maintenance, with visibility and banner settings based on linked incident details. * Status page data is available through a new API endpoint, with caching for successful responses and degraded results. * **Bug Fixes** * Status page data can still display when some linked incident details are unavailable; affected results are marked as degraded. * Improved handling of invalid widget entries so they don’t prevent valid items from being processed. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Claude Code <charis@supabase.io> |
||
|
Monica Khoury
|
1b5a806963 |
fix: show support contact message if Studio fails to load (FE-4460) (#50872)
## Summary
- Adds a fallback message ("Taking longer than expected?... contact
support@supabase.io") shown after 7s if Studio fails to fully load, for
the Next.js runtime — mirrors the existing TanStack-only
`ShellFallback`, which had no Next.js equivalent
- Fixes the support email in the existing TanStack `ShellFallback` (was
`support@supabase.com`, should be `support@supabase.io`)
- Extracts the shared copy (message, email, delay) into one file so both
fallbacks stay in sync
## Why
Linear FE-4460: users reported the Dashboard going completely blank with
no way to reach support when a JS chunk failed to load. The Next.js
runtime (the current default) had no fallback at all for this case.
## Test plan
- [ ] Normal page load: fallback never appears
- [ ] Simulated stuck boot (mount signal disabled): fallback appears
after 7s with correct copy/email, no layout bugs
- [ ] Same two checks on the TanStack runtime
(`STUDIO_FRAMEWORK=tanstack`)
- [ ] `pnpm --filter studio run typecheck` / `lint:ratchet` pass
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Added a loading fallback that appears if the app takes too long to
load, with guidance to clear browser cookies and reload.
* On self-hosted platforms, the fallback includes a support contact
link.
* The fallback is automatically hidden once the app loads.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
|
||
|
claude[bot]andClaude
|
f0e0865acc |
chore(studio): promote zero-baseline eslint ratchet rules to error (#50977)
<!-- ccr-slack-attribution --> _Requested by **Charis Lam** · [Slack thread](https://supabase.slack.com/archives/C0161K73J1J/p1790599888647059?thread_ts=1790599888.647059&cid=C0161K73J1J)_ ## Problem The Studio ESLint "ratchet" (`apps/studio/scripts/ratchet-eslint-rules.ts`, baseline in `apps/studio/.github/eslint-rule-baselines.json`, tracked rules in `apps/studio/scripts/ratchet-rules.json`) lets certain rules stay at `warn` severity while CI blocks the *count* of violations from increasing. Several of those tracked rules had already reached a baseline of 0 allowed violations, meaning there's nothing left to ratchet — they should be enforced directly instead of tracked indirectly. ## Solution **Before:** `no-restricted-imports`, `jsx-a11y/aria-props`, `jsx-a11y/aria-proptypes`, `jsx-a11y/role-supports-aria-props`, `jsx-a11y/anchor-has-content`, `jsx-a11y/aria-role`, `jsx-a11y/no-aria-hidden-on-focusable`, `jsx-a11y/tabindex-no-positive`, `jsx-a11y/no-distracting-elements`, and `react-hook-form/no-use-watch` were all tracked in the ratchet baseline with a count of 0, and (apart from `no-restricted-imports`, see below) configured as ESLint `warn` in `apps/studio/eslint.config.cjs`. **After:** each of those rules is removed from `apps/studio/.github/eslint-rule-baselines.json` (both the `rules` count and the now-empty `ruleFiles` entry) and from `apps/studio/scripts/ratchet-rules.json`. Their severity in `apps/studio/eslint.config.cjs` is bumped from `warn` to `error` so they're enforced directly by lint going forward instead of being tracked via the ratchet. `no-restricted-imports` was a special case: a later config block in `apps/studio/eslint.config.cjs` already overrides the shared `warn` default with `error` (confirmed via `eslint --print-config`), so only the ratchet bookkeeping needed removing for that rule — no severity change was needed. Promoting `jsx-a11y/role-supports-aria-props` to `error` surfaced one real violation that the ratchet's non-test-file filter had been hiding: a mock `<button>` in `LocalDropdown.test.tsx` set `aria-checked`, which that role doesn't support. Removed the unused `aria-checked` attribute from the mock (it wasn't asserted on by any test). Every other rule still tracked by the ratchet (e.g. `@typescript-eslint/no-explicit-any`, `react-hooks/exhaustive-deps`, `no-restricted-exports`, …) has a baseline above 0 and was left untouched. ### How verified - `pnpm --filter studio run lint:ratchet` → `Stable: No regressions for selected rules.` - `pnpm --filter studio run lint` → `0 errors, 2430 warnings` (no new errors from the severity bumps) - `npx vitest run components/interfaces/LocalDropdown.test.tsx` → 3/3 passing after the mock fix - `npx prettier --check` on all touched files → clean - `npx tsc --noEmit` shows one pre-existing, unrelated error in `packages/ui-patterns` (reproduced identically on `master` before this change) ## Review instructions 1. Confirm `apps/studio/.github/eslint-rule-baselines.json` and `apps/studio/scripts/ratchet-rules.json` no longer list the 10 rules named above. 2. Confirm those same rules (except `no-restricted-imports`, already `error`) are now `'error'` in `apps/studio/eslint.config.cjs`. 3. Run `pnpm --filter studio run lint:ratchet` and `pnpm --filter studio run lint` locally to confirm both pass. ## Checklist Check all before review: - [x] I have read [CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/CONTRIBUTING.md) - [ ] If I wrote a new docs topic or edited an existing topic, I used the `/write-the-docs` or `/edit-the-docs` skill, which applies the docs [style guide](https://github.com/supabase/supabase/tree/master/apps/docs/style-guide) 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_01LZThbcWV5U1r5cvUDKPVQP --- _Generated by [Claude Code](https://claude.ai/code/session_01LZThbcWV5U1r5cvUDKPVQP)_ Co-authored-by: Claude <noreply@anthropic.com> |
||
|
supabase-supabase-autofixer[bot]andgithub-actions[bot]
|
3d8da2d827 |
[bot] Decrease ESLint ratchet baselines (#48332)
Automated weekly decrease of ESLint ratchet baselines. Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com> |
||
|
|
7994191e49 |
feat(studio): group consecutive assistant tool calls (#50893)
<img width="913" height="572" alt="image" src="https://github.com/user-attachments/assets/e8112085-508a-49e4-abb1-7550248e611e" /> ## Problem A single Assistant response often produces 10+ reasoning and lookup rows ("Reasoned", "Ran search_docs", …). They push the answer down the chat, use raw tool names, and a fast tool call flashes past before the row goes back to "Thinking...". ## Solution Consecutive reasoning and lookup rows fold into one collapsible group. - **Running:** the header shows a tool only while it executes ("Checking policies in public..."). Between calls it reads "Thinking...", however long that lasts. Each header label stays up for at least 1 second, so quick calls no longer flash. - **Finished:** the header lists what the tools did, e.g. "Searched docs and checked policies", or "…, and 2 more". - **Expanded (any time):** every call is listed under a vertical rule. Rows still in progress shimmer, including several at once for parallel calls. ## How to test 1. Run `pnpm dev:studio` and open the Assistant on a project with a few tables. 2. Ask something that needs several lookups, e.g. "What RLS policies do I have and what do the docs recommend for them?" 3. While it streams, check the collapsed header: - It shows each tool while it runs, then goes back to "Thinking..." between calls. - Labels don't flash. Each stays up for about a second. - Only the shimmer marks progress, with no blinking cursor underneath. 4. Expand the group mid-stream. Rows read like "Checking policies in public..." rather than tool names, and only rows still in progress shimmer. 5. When it finishes, the header lists the actions ("Searched docs and checked policies") and stops shimmering. 6. Press Stop while a group is running. The unfinished row reads "Response interrupted" and stops spinning. 7. Reload the chat. Older groups show their collapsed summaries. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * AI assistant tool activity is grouped into collapsible sections with progress labels while work is underway and summaries when complete. * Expand grouped activity to review reasoning and tool details. Active tools and reasoning are highlighted, while completed reasoning without text is hidden. * Progress labels remain visible briefly during transitions, and active responses display a shimmer effect. * **Bug Fixes** * The loading indicator no longer appears while the assistant is processing a tool group. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com> Co-authored-by: Joshen Lim <joshenlimek@gmail.com> |