supabase / supabase / 42638155676

87%

push

github

feat(studio): split SQL errors into user and Studio SQL (#53059)

Part of FE-4772.

## Why

Errors from the pg-meta query endpoint didn't say who wrote the SQL, so
a Sentry issue like SUPABASE-APP-KXE couldn't tell a user's query from
one Studio composed. That event came from the assistant's `execute_sql`
tool and was captured by the Vercel AI integration on the server, so it
skipped `reportStudioError` and had no fault tags. The Postgres message
also went to Sentry as-is, and it can contain user SQL and data.

## What

- **`sqlOrigin` is required on `executeSql`.** `'user'` covers SQL the
user or an AI agent wrote, in whole or in part: SQL editor, editor
panel, Explorer, AI `execute_sql` and `run_notebook`, report blocks,
Query Insights EXPLAIN, the policy, function, and cron editors, and
running a stored cron job. Everything else is `'studio'`. The policy,
function, and cron mutation hooks and `useDbQuery` take `sqlOrigin` too.
- **`classifySqlResponseError`** turns a 400 from the query endpoint
into `UserSqlError` (`user`, `user_sql`) or `StudioSqlError` (`studio`,
`studio_sql`). Pattern rules (connection timeouts) and other statuses
keep their classes.
- **`UserSqlError` never reaches Sentry.** Its routing is
`SAMPLE_NEVER`, `alwaysCapture` doesn't override it, and `beforeSend`
drops it.
- **`StudioSqlError` is redacted.** Error classes can set
`sentryMessage`; for `StudioSqlError` it is the SQLSTATE and the query's
`queryName`, a static name that `executeSql` requires for Studio SQL.
The query key is never reported, since its segments can hold IDs,
schemas, and search terms. `applyStudioErrorPolicy` applies it from
`beforeSend` on the client and the server, so it holds however the error
was captured. The server config gets a `beforeSend` for this. Events get
`query_name` and `sql_state` tags and are grouped by both, since every
SQL error shares the `executeSql` stack.
- **A custom `handleError` gets the classified error**, matching its
declared t... (continued)

2094 of 2467 branches covered (84.88%)

Branch coverage included in aggregate %.

16 of 16 new or added lines in 4 files covered. (100.0%)

2883 of 3242 relevant lines covered (88.93%)

200.47 hits per line