## Summary
Fixes
[FE-3987](https://linear.app/supabase/issue/FE-3987/contact-support-pre-fills-the-wrong-supabase-project-id):
the "Contact support" button shown in the Table Editor's inline error
banner (e.g. "Failed to retrieve rows from table") didn't pass the
current project or organization to the support form. This caused the
support form to fall back to the user's first organization/project
instead of the one actually affected — especially noticeable when the
Management API request used to resolve the org also fails.
## Test plan
- [ ] Open a project in Studio, go to **Table Editor**, open a table.
- [ ] Trigger a failing table query — either block the `rest/v1/<table>`
request in DevTools, or apply a filter with a mismatched type (e.g. `id
= 'abc'` on an int column).
- [ ] On the inline red "Failed to retrieve rows from table" banner,
click **Contact support**.
- [ ] Confirm the support form pre-fills the **correct organization and
project** — the one the failing table actually belongs to.
- [ ] Repeat with a project belonging to an organization that is *not*
first in your org list, to confirm it's not coincidentally correct.
- [ ] Repeat while simulating a Management API failure (e.g. block
`api.supabase.com`/`*.supabase.co/platform/*`) to confirm the org still
resolves correctly via the `orgSlug` fallback instead of silently
defaulting to your first org.
- [ ] Sanity check other "Contact support" entry points (header Feedback
dropdown, Help sidebar) are unaffected — they use a separate,
already-correct code path.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Bug Fixes**
* Improved error handling when project details cannot be loaded,
preserving relevant project and organization context.
* Improved fallback behavior for identifying the correct organization
when project information is unavailable or unresolved.
* Support requests opened from error messages now include applicable
project and organization information.
* Error messages now consistently display available additional actions
alongside contact support options.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Joshen Lim <joshenlimek@gmail.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
