Files
supabase/apps/studio/data/feedback/support-ticket-send.ts
Jordi Enric 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

122 lines
3.2 KiB
TypeScript

import { useMutation } from '@tanstack/react-query'
import { toast } from 'sonner'
// End of third-party imports
import type { ExtendedSupportCategories } from '@/components/interfaces/Support/Support.constants'
import { handleError, post } from '@/data/fetchers'
import { ResponseError } from '@/types'
import type { UseCustomMutationOptions } from '@/types'
export type sendSupportTicketVariables = {
subject: string
message: string
category: ExtendedSupportCategories
severity: string
projectRef?: string
organizationSlug?: string
library?: string
affectedServices?: string
browserInformation?: string
allowSupportAccess: boolean
siteUrl?: string
additionalRedirectUrls?: string
dashboardSentryIssueId?: string
dashboardLogs?: string
dashboardStudioVersion?: string
}
const RATE_LIMIT_FALLBACK_SECONDS = 60
export async function sendSupportTicket({
subject,
message,
category,
severity,
projectRef,
organizationSlug,
library,
affectedServices,
browserInformation,
allowSupportAccess,
siteUrl,
additionalRedirectUrls,
dashboardSentryIssueId,
dashboardLogs,
dashboardStudioVersion,
}: sendSupportTicketVariables) {
const { data, error, response } = await post('/platform/feedback/send', {
body: {
subject,
message,
category,
severity,
projectRef,
organizationSlug,
library,
verified: true,
tags: ['dashboard-support-form'],
siteUrl,
additionalRedirectUrls,
affectedServices,
browserInformation,
allowSupportAccess,
dashboardSentryIssueId,
dashboardLogs,
dashboardStudioVersion,
},
})
if (error) {
const httpResponse: unknown = response
if (httpResponse instanceof Response && httpResponse.status === 429) {
const resetHeader =
httpResponse.headers.get('Retry-After') ?? httpResponse.headers.get('X-RateLimit-Reset')
const parsedReset = resetHeader ? parseInt(resetHeader, 10) : NaN
const waitSeconds = Number.isFinite(parsedReset) ? parsedReset : RATE_LIMIT_FALLBACK_SECONDS
throw new ResponseError(
`You have submitted too many support requests. Please try again in ${waitSeconds} second${waitSeconds === 1 ? '' : 's'}.`,
429,
undefined,
waitSeconds
)
}
handleError(error, {
alwaysCapture: true,
sentryContext: {
tags: {
dashboardSupportForm: true,
},
},
})
}
return data
}
type sendSupportTicketData = Awaited<ReturnType<typeof sendSupportTicket>>
export const useSendSupportTicketMutation = ({
onSuccess,
onError,
...options
}: Omit<
UseCustomMutationOptions<sendSupportTicketData, ResponseError, sendSupportTicketVariables>,
'mutationFn'
> = {}) => {
return useMutation<sendSupportTicketData, ResponseError, sendSupportTicketVariables>({
mutationFn: (vars) => sendSupportTicket(vars),
async onSuccess(data, variables, context) {
await onSuccess?.(data, variables, context)
},
async onError(data, variables, context) {
if (onError === undefined) {
toast.error(`Failed to submit support ticket: ${data.message}`)
} else {
onError(data, variables, context)
}
},
...options,
})
}