<!-- ccr-slack-attribution -->
_Requested via [Slack
thread](https://supabase.slack.com/archives/C063LNYJJKS/p1786454906416269?thread_ts=1786454906.416269&cid=C063LNYJJKS)_
## 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?
Chore / CI reliability. One-line config change to
`apps/studio/vitest.config.ts`.
## What is the current behavior?
**Before:** the `Studio Unit Tests & Build Check` workflow sometimes
goes red on `master` for no reason anyone can act on. Since 2026-07-29
it failed 3 out of 82 test executions (3.7%), every time at job `test
(1)`, step `Run Tests`. Every one of those three passed on a re-run with
no code change:
- https://github.com/supabase/supabase/actions/runs/31495760766
(`4587d177`, Aug 11)
- https://github.com/supabase/supabase/actions/runs/31409667566
(`b04d1485`, Aug 10)
- https://github.com/supabase/supabase/actions/runs/31203465483
(`777c02c2`, Aug 7)
Each failure also posts a Slack alert to #team-frontend-alerts via
`.github/workflows/studio-master-alert.yml`, so someone gets pinged,
opens the run, clicks re-run, and it goes green.
## What is the new behavior?
**After:** a test that fails in CI gets up to two more attempts before
the job is marked failed. A genuinely broken test still fails all three
attempts and still goes red. Locally nothing changes — the first failure
is the result you see, so you are never waiting on retries while
debugging.
## Additional context
**How:** added `retry: IS_CI ? 2 : 0` to the `test` block of
`apps/studio/vitest.config.ts`, with `const IS_CI = !!process.env.CI`
matching the pattern already used in
`e2e/studio/playwright.config.ts:51` (`retries: IS_CI ? 5 : 0`).
**Known limitation — we do not know which test is flaking.** The GitHub
Actions log downloads for those three runs were not retrievable, and the
API only surfaces `Process completed with exit code 1`. So this treats
the symptom without naming the cause.
The natural follow-up is to upload a JUnit or JSON vitest report as an
artifact with `if: always()`, which would name the flaking test on the
next failure. That is deliberately **not** in this PR — it is a workflow
change and was scoped out.
One more honest caveat: per-test retry only helps if the failure is an
assertion or timeout inside a test. If the real cause is a worker crash
or OOM, retrying will not save the run. That is a live possibility here
— the workflow sets `NODE_OPTIONS: '--max_old_space_size=3072'` with the
in-repo comment "Default is 2 GB, increase to have less frequent OOM
errors", which says someone has already hit memory pressure in this job.
So: worth landing as a cheap reduction in false alarms, but if the 3.7%
does not drop, the report artifact is the next step rather than more
retries.
---
_Generated by [Claude
Code](https://claude.ai/code/session_01U4338RsMYAc1uGuwTFNGBD)_
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: Ali Waseem <waseema393@gmail.com>
## 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>
* Refactor `StorageMenu` modals to replace deprecated patterns
* add test for `DeleteBucketModal` and update test setup
Note: Because this component uses `useParams`, it's necessary to have the dynamic route segment passed to `next-router-mock`'s `createDynamicRouteParser`. In order not to have to manually list all of these as the application grows, I added a glob utility that uses the `pages/` directory to automatically generate an array of dynamic route paths in this case.
* add test for `EmptyBucketModal`
* add test for `EditBucketModal` and add `isNonNullable` utility function
* add test for `CreateBucketModal`
* implement requested changes
* implement visual fixes
* Update studio testing setup files
Improves API mocking type safety and polyfills browser APIs necessary to run tests with framer-motion components
* fix missing listen call for msw, resolve test type error
* fix imports
* Update studio testing setup files
Improves API mocking type safety and polyfills browser APIs necessary to run tests with framer-motion components
* fix missing listen call for msw, resolve test type error
* fix imports
* Move non-layout Storage related components to `components/interfaces`
* Fix paths
---------
Co-authored-by: Joshen Lim <joshenlimek@gmail.com>
* Deprecate use of getWithTimeout, refactor BuildingState and RestoringState to use RQ
* Refactor profile-create-mutation to use data/fetchers, and edge-function-status-query to use fetch
* Shift post from lib/common/fetch, refactor bucket-object-download-mutation
* Address feedback
* Minor fix
* Refactor post calls from lib/common/fetch in auth pages to data/fetchers
* Add missing POST users endpoint + small fix when deleting user via context menu
* Remove all use of any imports from lib/common/fetch
* Clean up remaining usage of lib/common/fetch
* Fix fetchHeadWithTimeout
* simplify handleFetchError
* allow handleFetchError to accept unknown
* non-breaking change
* small fixes
* fix query path
---------
Co-authored-by: Alaister Young <a@alaisteryoung.com>
