## What kind of change does this PR introduce? Bug fix. ## What is the current behavior? Stripe Projects confirmation failures only appear in a toast. The existing **Unable to load authorization** Admonition is a separate error state shown when the account request itself cannot be loaded. ## What is the new behavior? Confirmation failures remain visible below the authorisation actions, clear on retry, and do not also trigger a toast. They use the shared `InterstitialActionError`. | Before | After | | --- | --- | | <img width="1024" height="759" alt="Authorize Stripe Projects Supabase" src="https://github.com/user-attachments/assets/83cb3144-9ddb-46b7-bfce-970497be61e2" /> | <img width="1024" height="759" alt="Authorize Stripe Projects Supabase" src="https://github.com/user-attachments/assets/bccedde9-9935-457b-a980-0c80499f2f27" /> | ## To test These instructions visually check the after state on this branch. Opening an invalid `ar_id` without the hardcodes only exercises the existing load-error Admonition, which this PR does not change. ### After on this branch 1. In `apps/studio/pages/partners/stripe/projects/login.tsx`, replace the `confirmationError` assignment with: ```tsx const confirmationError = 'Failed to authorize Stripe Projects: Test error' ``` 2. In the same file, replace the block beginning with `const linkedOrg` and ending with `interstitialDescription` with: ```tsx const linkedOrg = { name: 'Example Organization' } const emailMatches = true const displayName = primaryEmail ?? username ?? 'reviewer@example.com' const isPending = false const isConfirmed = false const isConfirming = false const isError = false const showAuthorizationState = true const interstitialDescription = 'This will create an organization on your behalf in Supabase' ``` 3. While signed in locally, open `http://localhost:8082/partners/stripe/projects/login?ar_id=test`. 4. Confirm the error appears below **Authorize Stripe Projects** and **Cancel**. No real Stripe request is required. 5. Revert both temporary edits. ### Before on master (optional) 1. Check out `master`. 2. In `apps/studio/pages/partners/stripe/projects/login.tsx`, replace the block beginning with `const linkedOrg` and ending with `interstitialDescription` with the same block from step 2 above. Do not add `confirmationError`. 3. While signed in locally, open `http://localhost:8082/partners/stripe/projects/login?ar_id=test`. 4. Click **Authorize Stripe Projects**. 5. Confirm the failed confirmation appears in a toast beginning **Failed to confirm account request**. 6. Revert the temporary edit before changing branches. ## Additional context Stacked on #48471. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit ## Summary by CodeRabbit * **Bug Fixes** * Authorization errors during Stripe Projects login are now displayed inline in both authorization flows. * Authorization remains available after a failed confirmation attempt. * Failed authorization requests no longer trigger an additional toast notification. * Previous errors are cleared when retrying authorization. <!-- end of auto-generated comment: release notes by coderabbit.ai -->
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')