Jordi Enric
ec26943390
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
Supabase Design System
Design resources for building consistent user experiences at Supabase.
Getting started
First, make a copy of .env.local.example and name it env.local. Then install any required packages and start the development server:
cd apps/design-system
pnpm i
pnpm dev:full
The dev:full command runs both the Next.js development server and Contentlayer concurrently, which is recommended for most development workflows.
Alternative commands
You can also run the development server and content watcher separately:
# Run only the Next.js development server
pnpm dev
# Run only the content watcher (in a separate terminal shell)
pnpm content:dev
Or run the development server from the root directory:
pnpm dev:design-system
To run both the development server and content watcher from the root directory, you can use:
# Run the development server
pnpm dev:design-system
# Run the content watcher (in a separate terminal shell)
pnpm --filter=design-system content:dev
Open http://localhost:3003 in your browser to see the result.
Watching for MDX changes
The dev:full command automatically watches for changes to MDX files with hot reload. If you're running the pnpm dev separately, you'll need to run pnpm content:dev in a separate terminal shell to watch for content changes.
Adding components
The design system references components rather than housing them. That’s an important distinction to make, as everything that follows here is about the documentation of components. You can add or edit components in one of these two places:
packages/ui: basic UI componentspackages/ui-patterns: components which are built using NPM libraries or amalgamations of components frompatterns/ui
There are several parts of this design system that need to be manually updated after components have been added or removed (from documentation). These include:
config/docs.ts: list of components in the sidebarcontent/docs: the actual component documentationregistry/examples.ts: list of example componentsregistry/fragments.ts: list of fragment componentsregistry/charts.ts: list of chart componentsregistry/default/example/*: the actual example components
You will need to rebuild the design system’s registry after making new additions:
cd apps/design-system
pnpm build:registry