Files
supabase/apps/studio/tests
Alaister YoungandAlaister Young b9df7aaf9e [FE-3711] feat(studio): make compute config read-only for HA projects (#49359)
Makes the compute-size configuration on Settings → Infrastructure
read-only for High Availability (Multigres) projects during Alpha — HA
projects run on a single fixed compute size and resizing isn't supported
yet (previously attempting one could leave a project stuck Resizing).

Gated on `project.high_availability` via the existing
`useHighAvailability()` hook — the same signal every other HA gate in
Studio uses.

**Changed:**
- Compute size options other than the project's current size render with
the existing locked treatment (greyed out, lock icon, tooltip) for HA
projects, and the whole radio group is disabled
- A `HighAvailabilityDisabledSectionNotice` in the Compute section
explains that HA projects run on a fixed compute size during Alpha
- The compute branch of `onSubmit` and the read-replica
compute-recommendation handoff are skipped for HA projects, so a compute
change can never reach `POST /billing/addons`
- The "Contact Us" larger-sizes card is hidden for HA projects
- Form initialization now also fires once the project loads for HA
projects (disk-attribute queries never run on their cloud provider, so
the existing reset effect never fired and the picker showed the
`ci_micro` fallback as selected)

**Added:**
- Two MSW page tests in the Infrastructure suite covering the HA
read-only state and the unchanged editable state for non-HA projects

## To test

- On an HA (Multigres) project: Settings → Infrastructure should show a
notice under Compute size, the project's current size selected, every
other size locked with a tooltip, no "Contact Us" card, and clicking any
option should never surface the "Review changes" bar
- On a regular project: compute selection, "Review changes" → "Confirm
changes", and the Contact Us card all behave as before
- `pnpm vitest run
"tests/pages/project/[ref]/settings/infrastructure.test.tsx"`

Addresses
[FE-3711](https://linear.app/supabase/issue/FE-3711/make-compute-configuration-read-only-for-mvp)

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

## Summary by CodeRabbit

* **New Features**
* Added High Availability notices and guidance to the Compute settings.
* High Availability projects now show compute sizes as read-only, with
explanations for unavailable options.
* Hid the larger-instance contact option for High Availability projects.

* **Bug Fixes**
* Prevented unsupported compute resizing and add-on changes for High
Availability projects.
  * Preserved compute resizing and review actions for standard projects.

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

---------

Co-authored-by: Alaister Young <10985857+alaister@users.noreply.github.com>
2026-08-24 16:09:43 +08:00
..

UI Testing Notes

Rules

  • All tests should be run consistently (avoid situations whereby tests fails "sometimes")

  • Group tests in folders based on the feature they are testing. Avoid file/folder based folder names since those can change and we will forget to update the tests.

Examples: /logs /reports /projects /database-settings /auth

Custom Render and Custom Render Hook

customRender and customRenderHook are wrappers around render and renderHook that add some necessary providers like QueryClientProvider, TooltipProvider and NuqsTestingAdapter.

Generally use those instead of the default render and renderHook functions.

import { customRender, customRenderHook } from 'tests/lib/custom-render'

customRender(<MyComponent />)
customRenderHook(() => useMyHook())

Mocking API Requests

To mock API requests, we use the msw library.

Global mocks can be found in tests/lib/msw-global-api-mocks.ts.

To mock an endpoint you can use the addAPIMock function. Make sure to add the mock in the beforeEach hook. It won't work with beforeAll if you have many tests.

beforeEach(() => {
  addAPIMock({
    method: 'get',
    path: '/api/my-endpoint',
    response: {
      data: { foo: 'bar' },
    },
  })
})

API Mocking Tips:

  • Keep mocks in the same folder as the tests that use them
  • Add a test to verify the mock is working

This will make debugging and updating the mocks easier.

test('mock is working', async () => {
  const response = await fetch('/api/my-endpoint')
  expect(response.json()).resolves.toEqual({ data: { foo: 'bar' } })
})

Mocking Nuqs URL Parameters

To render a component that uses Nuqs with some predefined query parameters, you can use customRender with the nuqs prop.


customRender(<MyComponent />, {
  nuqs: {
    searchParams: {
      search: 'hello world',
    },
  },
})

<Popover> vs <Dropdown>

When simulating clicks on these components, do the following:

// for Popovers
import userEvent from '@testing-library/user-event'
await userEvent.click('Hello world')

// for Dropdowns
import clickDropdown from 'tests/helpers'
clickDropdown('Hello world')