Files
supabase/apps/studio/components/interfaces/Support/SupportForm.state.ts
T
Jordi EnricandClaude Sonnet 4.6 42ca11f89e fix(support): handle rate-limited support submissions gracefully (#46928)
## Problem

When a support ticket submission is rejected by the API's rate limiter,
the form surfaced the raw server exception text to the user and reported
every rejection as an application error. This produced a steady stream
of noisy error reports for what is actually expected, recoverable
behavior.

The rejections are not random: the submit endpoint allows only a small
number of requests in a short window, so a quick second submission (a
fast retry or a follow-up ticket moments later) gets rejected. The first
submission usually succeeds; it's the immediate follow-up that fails.
Surfacing the raw error and logging it made this look worse than it is.

Separately, the success screen had only top padding, leaving its actions
flush against the bottom edge of the card.

## Fix

- Detect the rate-limit response and show a clear, friendly message that
tells the user how long to wait before trying again, instead of the raw
exception text.
- Stop reporting rate-limit rejections as errors to our monitoring. They
are expected and recoverable, so they no longer add noise.
- Give the success state the same vertical padding as the rest of the
form so its actions are not flush against the card edge.

## How to test

- Open the support form and simulate a 429 from the submit endpoint.
- Expected: a friendly message telling the user when they can retry, and
no error reported to monitoring.
- Submit a ticket successfully and confirm the success screen has even
padding above and below its content.

## Notes

This covers the user-facing handling. The rate-limit threshold itself is
tuned conservatively on the API and can be revisited separately so that
ordinary, legitimate resubmissions are not caught.

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

* **Bug Fixes**
* Improved support form handling for rate-limited (429) submissions by
suppressing unnecessary error reporting while still showing the error
and returning the form to editing.
* Fixed inconsistent support form spacing so padding is consistent
regardless of submission outcome.
* **Improvements**
* Propagated backend error `code` through the support-ticket submission
flow so the UI can react more intelligently to failures (including 429
retry-window messaging).
* Enhanced retry timing extraction for rate-limited errors by using
`Retry-After` with a fallback to rate-limit reset data.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->

---------

Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
2026-06-16 14:58:48 +00:00

113 lines
3.1 KiB
TypeScript

import type { ExtendedSupportCategories } from './Support.constants'
import type { SupportFormValues } from './SupportForm.schema'
import { neverGuard } from '@/lib/helpers'
export type SubmittedSupportRequest = Pick<
SupportFormValues,
'category' | 'severity' | 'subject' | 'message' | 'affectedServices' | 'allowSupportAccess'
> & {
organizationSlug: string | undefined
projectRef: string | undefined
library?: string
dashboardLogs?: string
}
export type SupportFormState =
| {
type: 'initializing'
}
| {
type: 'editing'
}
| {
type: 'submitting'
}
| {
type: 'success'
sentProjectRef: string | undefined
sentOrgSlug: string | undefined
sentCategory: ExtendedSupportCategories
submittedRequest: SubmittedSupportRequest
}
| {
type: 'error'
message: string
code?: number
}
export type SupportFormActions =
| { type: 'INITIALIZE'; debugSource?: string }
| { type: 'SUBMIT'; debugSource?: string }
| {
type: 'SUCCESS'
sentProjectRef: string | undefined
sentOrgSlug: string | undefined
sentCategory: ExtendedSupportCategories
submittedRequest: SubmittedSupportRequest
debugSource?: string
}
| { type: 'ERROR'; message: string; code?: number; debugSource?: string }
| { type: 'RETURN_TO_EDITING'; debugSource?: string }
export function createInitialSupportFormState(): SupportFormState {
return {
type: 'initializing',
}
}
export function supportFormReducer(
state: SupportFormState,
action: SupportFormActions
): SupportFormState {
switch (state.type) {
case 'initializing':
if (action.type === 'INITIALIZE') {
return { type: 'editing' }
}
console.warn(
`[SupportForm > supportFormReducer] ${action.type} action not allowed in 'initializing' state`
)
return state
case 'editing':
if (action.type === 'SUBMIT') {
return { type: 'submitting' }
}
console.warn(
`[SupportForm > supportFromReducer] ${action.type} action not allowed in 'filling_out' state`
)
return state
case 'submitting':
if (action.type === 'SUCCESS') {
return {
type: 'success',
sentProjectRef: action.sentProjectRef,
sentOrgSlug: action.sentOrgSlug,
sentCategory: action.sentCategory,
submittedRequest: action.submittedRequest,
}
}
if (action.type === 'ERROR') {
return {
type: 'error',
message: action.message,
code: action.code,
}
}
console.warn(
`[SupportForm > supportFormReducer] ${action.type} action not allowed in 'submitting' state`
)
return state
case 'success':
console.warn(`[SupportForm > supportFormReducer] ${action.type} allowed in 'success' state`)
return state
case 'error':
if (action.type === 'RETURN_TO_EDITING') {
return { type: 'editing' }
}
console.warn(`[SupportForm > supportFormReducer] ${action.type} allowed in 'success' state`)
return state
default:
return neverGuard(state)
}
}