## 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>
## 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?
Cases with cloudflares http/3 the content-length header is optional, so
in many cases we need to make sure in this case `openapi-fetch` can
safely parse this (i.e ignore when the body is empty and no header is
present)
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
## Release Notes
* **Bug Fixes**
* Fixed JSON parsing failures when successful API responses contain
empty bodies without `Content-Length` headers. Improves compatibility
with HTTP/3 and similar response types.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
Preserve `formattedError` through the `ResponseError` path and fall back
to splitting `error.message` on newlines so enhanced permission-denied
HINTs from supabase/postgres#2084 render as separate lines in the SQL
editor — users can actually read the GRANT example now.
**Context:** postgres#2084 adds a multi-line HINT to SQLSTATE 42501
errors, telling users exactly how to grant access per-table. Today the
SQL editor rendered the whole thing on one line because `formattedError`
was stripped by the fetchers' error handling and the `message` fallback
didn't split on `\n`. This PR fixes both.
Blocks [FE-3023](https://linear.app/supabase/issue/FE-3023) — the
project-creation toggle that flips default privileges; without readable
HINTs users land on RLS debugging rabbit holes when they hit a
permission denied.
**Changed:**
- `ResponseError` now carries an optional `formattedError` field;
`ConnectionTimeoutError` / `UnknownAPIResponseError` thread it through.
- `handleError` in `data/fetchers.ts` extracts `formattedError` from the
raw error body and forwards it to the thrown subclass.
- `UtilityTabResults.tsx` uses a new `getSqlErrorLines` helper — prefers
`formattedError`, falls back to splitting `message` on newlines when
it's multi-line (defense in depth since the exact field pg-meta
populates for the HINT depends on the path). Copy button now uses the
same lines.
**Added:**
- `getSqlErrorLines` pure helper + 9 unit tests.
- 5 new tests in `handleError.test.ts` covering `formattedError`
preservation on classified and unclassified errors.
## To test
1. Pull the branch, run `pnpm dev:studio`, open any project's SQL
editor.
2. Run a query that triggers the enhanced HINT (requires postgres#2084
deployed on the DB — currently staging-only). Example: `select * from
some_table_you_cant_read;` as a role without grants.
3. Expect the ERROR line, HINT line, and the `GRANT ...` example to each
render on their own `<pre>` line, plus the Copy button to copy the full
multi-line text.
4. Sanity check existing single-line errors (e.g. `select * from
nonexistent_table`) still render as `Error: relation "nonexistent_table"
does not exist` in the `<p>` fallback.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
## Release Notes
* **New Features**
* Improved SQL error message formatting in the editor for better
readability and clarity.
* **Refactor**
* Centralized error formatting logic for more consistent error
presentation across the application.
* **Tests**
* Added comprehensive test coverage for SQL error message parsing and
formatting.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
Co-authored-by: Alaister Young <10985857+alaister@users.noreply.github.com>
When the dashboard hits a DB connection timeout, users currently see a
raw error message with no
path forward. This PR adds an inline troubleshooting system that detects
known error types and
surfaces contextual next steps — restart the DB, read the docs, or debug
with AI.
## Changes
- New ErrorDisplay component (packages/ui-patterns) — styled error card
with a title, monospace error
block, optional troubleshooting slot, and a "Contact support" link that
always renders. Accepts
typed supportFormParams to pre-fill the support form.
- Error classification in handleError (data/fetchers.ts) — on every API
error, the message is tested
against ERROR_PATTERNS. If matched, handleError throws a typed subclass
(ConnectionTimeoutError
extends ResponseError) instead of a plain ResponseError. Stack traces
now show the exact error
class. All existing instanceof ResponseError checks continue to work.
- ErrorMatcher component — reads errorType from the thrown class
instance, does an O(1) lookup into
ERROR_MAPPINGS, and renders the matching troubleshooting accordion as
children of ErrorDisplay.
Falls back to plain ErrorDisplay for unclassified errors.
- Connection timeout mapping — first error type wired up, with three
troubleshooting steps: restart
the database, link to the docs, and "Debug with AI" (opens the AI
assistant sidebar with a
pre-filled prompt).
- Telemetry — three new typed events track when the troubleshooter is
shown, when accordion steps are
toggled, and which CTAs are clicked.
## Adding a new error type
1. Add a class to types/api-errors.ts
2. Add { pattern, ErrorClass } to data/error-patterns.ts
3. Create a troubleshooting component in errorMappings/
4. Add an entry to error-mappings.tsx
## Context
Part of an investigation to see how we can make the dashboard more
resilient for large databases by ensuring that the dashboard never
becomes the reason for taking down the database accidentally.
Am proposing that for interfaces that rely heavily on queries to the
database for data to render, we add preflight checks to ensure that we
never run queries that exceed a certain cost threshold (and also have UI
handlers to communicate this) - this can be done by running an EXPLAIN
query before running the actual query, and if the cost from the EXPLAIN
exceeds a specified threshold, the UI throws an error then and skips
calling the actual query.
## Demo
Am piloting this with the Table Editor, and got an example here in which
my table has 500K+ rows, and I'm trying to sort on an unindexed column:
https://github.com/user-attachments/assets/ccad2ea9-d62c-4106-8295-2a6df5941474
With this UX, the pros are that
- It's relatively seamless and not too invasive, most users won't notice
this unless they run into this specific scenario
- We can incrementally apply this to other parts of the dashboard, next
will probably be Auth Users for example
However there are some considerations:
- The additional EXPLAIN query adds a bit more latency to the query
since its a separate API request to the query endpoint
- ^ On a similar note, it will hammer the API a bit more, which may
result in higher probability of 429s
- However, I reckon that the preflight checks are meant to be used
sparingly and only for certain parts of the dashboard that we believe
may cause high load.
- e.g for the Table Editor, reckon we only need this for fetching rows?
The count query is largely optimized already (although we could just add
a preflight check there too)
- It's just meant to be a safeguard to prevent running heavy queries on
the database
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Query preflight with cost checks and a user-facing high-cost dialog
showing cost details and remediation suggestions.
* Grid exposes an explicit error flag and surfaces richer error
metadata.
* **Bug Fixes**
* Standardized error handling and more consistent error displays across
the app.
* Explain analysis now reports an additional max-cost metric for
queries.
* **UI**
* Tweaked empty-state interaction/layout and slightly wider header
delete control.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Ali Waseem <waseema393@gmail.com>
* feat: use mgmt-api's function body endpoint
* skip json files from static patterns
* set the default content for deno.json
* feat: add drag and drop file support to FileExplorerAndEditor
- Add drag and drop functionality to accept files
- Dropped files are automatically read and added to the files list
- Visual feedback with drag overlay during drag operations
- Files maintain existing data format with id, name, content, and selected state
- Last dropped file is automatically selected for editing
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-Authored-By: Claude <noreply@anthropic.com>
* feat: add binary file handling to FileExplorerAndEditor
- Add binary file detection for common file extensions (.wasm, images, executables, etc.)
- Show "Cannot Edit Selected File" error message when trying to edit binary files
- Binary files dropped via drag-and-drop retain their original binary content
- Only show error in editor view, files remain accessible in file list
- Text files continue to work normally with full editing capabilities
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-Authored-By: Claude <noreply@anthropic.com>
* do not ignore empty files
* exclude wasm files from static patterns
* Remove eszip parser test as dependency has been removed
* Fix TS issues
* Fix TS issues
* Fix pnpm-lock
* Fix
* Fix
* Nit
---------
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: Joshen Lim <joshenlimek@gmail.com>
* update handleError to pass sentry context
* no spread
* Fix the types for the sentry context.
---------
Co-authored-by: Ivan Vasilov <vasilov.ivan@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>
* 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
* simplify handleFetchError
* allow handleFetchError to accept unknown
* non-breaking change
---------
Co-authored-by: Alaister Young <a@alaisteryoung.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
* Smol fix
* Add custom error handler for fetch error 'Failed to fetch'
* Refactor EdgeFunctionTesterSheet to use react query instead of manually calling fetch
* Use new fetchHandler for where we're calling fetch
* Revert
* deploy edge function mutaton
* update url
* use openapi-fetch POST in the deploy mutation.
---------
Co-authored-by: Ivan Vasilov <vasilov.ivan@gmail.com>
* fix: response error codes
* upgrade docs
* remove request url modification middleware
* move api routes for self-hosted to platform folder
* remove some lib/common/fetch usage
* docs: use middleware for openapi-fetch (#30600)
Get rid of the unauthedAllowedPost function (I don't think there's any harm in letting any requests that require authentication to just 403, they should be disabled at the React Query level and if not they will fail gracefully enough...)
* fix local count query
* add default values for clone mutation
* fix ts and codegen
* add missing lodash dep to playwright tests
* Fix the playwright tests to match the new folder structure for selfhosted variant.
* remove unused import
* Remove unused state
* remove unused sql debug mutation
* remove unused export
* fix notifications query
* fix jwt updating status
* fix typescript
* save sql snippet after renaming
* update codegen & fix ts error
* override array querySerializer
---------
Co-authored-by: Charis <26616127+charislam@users.noreply.github.com>
Co-authored-by: Joshen Lim <joshenlimek@gmail.com>
Co-authored-by: Ivan Vasilov <vasilov.ivan@gmail.com>
* Add a beforeSend hook to sentry client config.
* Remove the canSendTelemetry function and all its uses.
* Use captureException for capturing unhandled error messages.
* Use Sentry Error boundary.
* Add a button for throwing error to test the sentry error boundary.
* trigger an error during rendering.
* Move the throwing of error.
* Fix the error boundary state.
* Try to throw an error from the project list.
* Revert to using react error boundary.
* Minor fixes.
* Add an example page for throwing an exception to be caught by Sentry. Remove the error filter from the Sentry client config.
* Remove config for allowing errors only from our code.
* When capturing an exception with Sentry, add a tag if the exception is in the boundary.
* Minor fixes.
* Remove testing code.
* Move forgotten code.
* Add a function for anonymized user id.
* Set the sentry user id by anonymizing the actual user id.
* Don't send Sentry reports if the user hasn't consented to the telemetry.
* Add a helper function whether the studio can send telemetry data.
* Reuse the helper function in the _app file.
* First round of wrapping RQ errors with handleError
* Remove the throw before the handleError usage.
* Make the handling of an API error more versatile. Add logging in Sentry if the error is of unknown type.
* Remove throwing of the handleError function.
* Add return type to the handleError function to be never so that we're sure it always throws.
---------
Co-authored-by: Ivan Vasilov <vasilov.ivan@gmail.com>
* Move all studio files from /studio to /apps/studio.
* Move studio specific prettier ignores.
* Fix the ui references from studio.
* Fix the css imports.
* Fix all package.json issues.
* Fix the prettier setup for the studio app.
* Add .turbo folder to prettierignore.
* Fix the github workflows.
