Stacked on #47657 (base is `alaister/tanstack-migration-fixes`; retarget
to `master` once that merges).
The TanStack runtime never ran `Sentry.init` —
`instrumentation-client.ts` is a Next-convention file nothing imports
under TanStack Start, so every `Sentry.captureException` on that build
(including the `routes/__root.tsx` error-boundary /
`routerErrorComponent` reports) was a silent no-op.
- **Shared config source**: the entire client config moves verbatim from
`instrumentation-client.ts` into `lib/sentry-client-options.ts`
(`buildSentryClientOptions`). Both runtimes build from it, so Next and
TanStack can't drift — the builds differ only in two explicit knobs.
- **TanStack init**: `sentry.tanstack.ts` initializes `@sentry/react`
from `getRouter()` (TanStack Start's real client bootstrap — the
earliest point with the router instance), wiring
`tanstackRouterBrowserTracingIntegration(router)`. Window-guarded +
idempotent; `router.tsx` is TanStack-only so the Next build is
untouched. (Named without `.client.` — Start's import-protection fails
the build for `*.client.*` in the server graph.)
- **Third-party error filter is intentionally Next-only**: without the
bundler-injected `applicationKey` metadata (only `withSentryConfig`
provides it), the SDK tags *every* event `third_party_code: true` and
`beforeSend` would drop them all — recreating the silent no-op with a
DSN set. Follow-up: add `@sentry/vite-plugin` moduleMetadata, then
enable.
- **DSN-less builds stay crash-free**: `vite.config.ts` inlines
`undefined` for unset
`NEXT_PUBLIC_SENTRY_DSN`/`NEXT_PUBLIC_SENTRY_ENVIRONMENT` (a literal
`process.env.*` in the bundle is the exact `process is not defined`
class #47657 fixed). No-DSN → disabled client, plus the existing
`IS_PLATFORM`/consent gates.
- Tests: `instrumentation-client.test.ts` moved to
`lib/sentry-client-options.test.ts` with all 36 assertions kept, plus
integration-gating and Next/TanStack parity tests. `tsc` clean; full
`vite build --mode test` passes.
Follow-up (separate): server-side Sentry for the Start handler
(`server.ts` entry + `@sentry/node`-style init).
## To test
- **Locally (no DSN set)**: load the TanStack build — no Sentry network
requests, no console errors, and crucially no `ReferenceError: process
is not defined` (the define fallback). Forcing an error must not POST to
any `/envelope` endpoint.
- **On a preview/deploy (DSN set, telemetry consent accepted)**: throw a
test error (e.g. crash a route component) → a POST to
`o…ingest.sentry.io/api/…/envelope/` fires, and the event lands in
Sentry with a `codeSampleRate` tag and **no** `third_party_code` tag.
Navigation spans named after TanStack routes appear when the 2% pageload
trace samples in.
- **Next build regression check**: the Next dev/preview still reports
errors exactly as before (`instrumentation-client.ts` now builds its
options from the same shared source).
---
### Review feedback: Sentry `/envelope` never fires on TanStack (Joshen)
Root-caused: `@sentry/core`'s `Client.sendSession` silently drops the
session when the client has no `release`. The Next build gets a release
injected by `withSentryConfig` (the Vercel commit SHA); the Vite build
runs no Sentry bundler plugin, so it had no release → session envelopes
were discarded before transport → zero `/envelope` traffic
(errors/transactions are separate). Fix: inject `release:
NEXT_PUBLIC_VERCEL_GIT_COMMIT_SHA` on the TanStack build (vite.config
re-exposes `VERCEL_GIT_COMMIT_SHA` under the `NEXT_PUBLIC_` name, same
SHA the Next release resolves to). Also switched `integrations` to the
function form so defaults are preserved by contract (not just by current
SDK behavior). 45 unit tests green.
**To test (deploys only — the SHA is unset locally, so this can't be
reproduced on a local dev build):** on this PR's Vercel preview with a
DSN + telemetry consent, load any page and watch the Network tab for a
POST to `…ingest.sentry.io/…/envelope/` — a session envelope should now
fire on load, matching the Next build.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Improved client-side error and performance monitoring for the Studio
app across both router setups.
* Added support for passing release/version information into monitoring
data.
* **Bug Fixes**
* Reduced noisy error reporting by better filtering common browser,
extension, cancellation, and load-related issues.
* Prevented browser bundles from referencing missing environment values
at runtime.
* Made monitoring initialization safer in server-rendered and
client-only environments.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Alaister Young <10985857+alaister@users.noreply.github.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?
Chore
## What is the current behavior?
100% of traces are being sent to Sentry, which alone would blew through
all of our quota leaving no spans available for other projects. For
April we are already rate limited.
## What is the new behavior?
Change `tracesSampleRate` to more reasonable value (0.02).
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Chores**
* Optimized performance monitoring sampling configuration to reduce
application overhead while maintaining essential error tracking and
diagnostics.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
Switch studio's package.json to `"type": "module"` so the package runs
as native ESM. This aligns the runtime module system with what we
actually write (`import`/`export`), improves tree-shaking, and reduces
friction with ESM-only dependencies.
**Changed:**
- `next.config.js` → `next.config.ts` – ESM imports/exports, proper TS
types, fixed type narrowing on redirect `has` and `basePath` fields
- `csp.js` → `csp.ts` – `module.exports.getCSP` → named `export
function`
- `tailwind.config.js` → `tailwind.config.ts` – ESM imports
- `postcss.config.js` – `module.exports` → `export default` (stays `.js`
since PostCSS doesn't support TS configs)
**Removed:**
- Unused `path` import in next config
- Deprecated Sentry `hideSourceMaps` option (default behavior in Sentry
v10)
**Added:**
- Type declaration for `config/tailwind.config` CJS package
## To test
- A general smoke test of studio should suffice
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Refactor**
* Modernized the Studio package to ES module style and improved
TypeScript typings and config declarations to reduce build/runtime
issues.
* Updated styling and post-processing configuration format for more
consistent tooling behavior.
* **Chores**
* Updated code ownership entries to reflect migrated/renamed
configuration files.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Alaister Young <10985857+alaister@users.noreply.github.com>
Sentry was flooded with un-actionable events: browser extension errors,
network blips, React hydration
noise from DOM-manipulating extensions, and CriticalError issues that
were impossible to route because
they grouped by message string rather than type. This made it hard to
spot real regressions.
## Changes:
- Improved client-side Sentry signal quality in
apps/studio/instrumentation-client.ts by replacing
custom third-party stack filtering with
Sentry.thirdPartyErrorFilterIntegration, plus stricter
allowUrls filtering for Supabase/app frames.
- Added build-time Sentry bundle annotation in
apps/studio/next.config.js via
unstable_sentryWebpackPluginOptions.applicationKey = 'supabase-studio'
to support reliable third-party
frame filtering.
- Expanded and reorganized ignoreErrors rules across client/server/edge
Sentry configs to suppress known
non-actionable noise (Next.js navigation internals, network/transient
chunk failures, extension/DOM-
manipulation noise, hydration-noise patterns).
- Refactored critical error reporting in
apps/studio/lib/error-reporting.ts from captureMessage to
captureException with scoped tags (critical=true, context=<action>) and
synthetic CriticalError
exceptions for better alerting/grouping.
- Updated tests in apps/studio/lib/error-reporting.test.ts to match the
new Sentry API usage (withScope
+ captureException) and assert on exception objects/tags behavior.
- 100% sampling (codeSampleRate = 1) for normal/useful errors.
- 1% sampling (codeSampleRate = 0.01) only for explicitly noisy classes:
- Failed to construct 'URL': Invalid URL
- Session error detected
- chunk-load failures (ChunkLoadError, Loading chunk ... failed, Loading
CSS chunk ... failed)
- Sent events are tagged with codeSampleRate so you can filter/segment
in Sentry dashboards.
---------
Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
## What kind of change does this PR introduce?
Grammar corrections in comments and user-facing text.
## What is the current behavior?
Several files have minor grammar issues:
- Missing contraction: "it an error" (should be "it's an error")
- Subject-verb disagreement: "a users loads" (should be "a user loads")
- Missing possessive apostrophe: "a users organization" and "a users
language" (should be "a user's")
## What is the new behavior?
All grammar issues are corrected:
- `apps/studio/instrumentation-client.ts` — "it's an error" + "a user
loads"
- `apps/docs/instrumentation-client.ts` — "a user loads"
- `apps/www/data/partners/index.tsx` — "a user's organization"
-
`apps/docs/content/troubleshooting/customizing-emails-by-language-KZ_38Q.mdx`
— "a user's language"
## 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?
We had these error ignores inside of sentry, doesn't make sense and
rather should live next to the code
- Added tracesSampleRate: 0.1 to all three Sentry configuration files
(client, server, edge)
- Captures 10% of transactions for performance monitoring
- Previously: No performance data was being collected (missing this
config)
- Now: Sentry will track route performance, error rates per route, and
transaction data
Why this was needed:
- Without tracesSampleRate, Sentry's Performance tab was empty
- Error rates per route were not visible
- No transaction/route-level metrics were being collected
- The SDK was only capturing errors without context about which routes
they occurred on
Impact:
- Enables route-based error tracking (see which endpoints/pages have
errors)
- Provides performance metrics per route (page load times, API response
times)
- Allows monitoring of Web Vitals and navigation performance
- 10% sample rate balances visibility with Sentry quota usage
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Bug Fixes**
* Fixed date display formatting in logs to ensure accurate timestamp
representation.
* **Chores**
* Enabled performance monitoring to collect transaction data and track
application behavior.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
* o11y: mirror and sanitize breadcrumbs
Mirror Sentry breadcrumbs as the basis for our own support logging. Also
adds more sanitization to breadcrumbs.
* feat(support form): toggle for attaching dashboard logs
Add a toggle to the support form when the category is "Dashboard bug",
to attach recent dashboard logs. Users can preview the attached logs and
opt out.
* feat(support links): dedicated support link component
Add a new component for support links, which:
- Uses the serializer for support link params to ensure
serialization/deserialization pairs correctly
- Snapshots breadcrumbs so the attached log on the support form will be
cut off at the support link click (otherwise we will get support form
actions cluttering up the log)
* tests(support form): extend timeout on flaky test
* Minor clean up
* fix(support form): allow url to specifically indicate no specified project
* minor nits
* Fix tests
* Fix tests
---------
Co-authored-by: Joshen Lim <joshenlimek@gmail.com>
