Skip to content

v0.161.2: Browser errors now actually reach Sentry

Choose a tag to compare

@github-actions github-actions released this 30 Jul 08:11
c30c199

What was broken

Sentry has been reporting nothing from the browser. The previous release turned Sentry back on and the server side genuinely worked — which is exactly why this went unnoticed. Errors from API routes and server rendering flowed into Sentry normally, so the dashboard looked alive, while every error your students actually hit in their browser was silently dropped.

That means all 21 error boundaries, session replay, and every breadcrumb reported nowhere. If a student's lesson page blew up client-side, the fallback UI rendered and you never heard about it.

Why

A file-name convention, not a logic bug — which is what made it invisible.

The app builds with Turbopack (Next 16's default). The Sentry SDK's Turbopack path bundles client config by matching **/instrumentation-client.* and nothing else. The old name sentry.client.config.ts is read only by the SDK's webpack path, which never runs here.

So the file type-checked, linted, imported cleanly, and read as perfectly correct in review — and was never included in the build. Sentry.init never executed in a browser.

The fix

Renaming sentry.client.config.tsinstrumentation-client.ts. That's the entire functional change; the file's contents were already correct, including an onRouterTransitionStart export that had been inert under the ignored name.

Also added a guard test that fails if the old name ever comes back. This failure mode is invisible to builds, type-checking, and lint, so a static check is the only thing that catches it — verified it fails 4 of 5 assertions when the legacy name is restored.

Verified

Against live production before the fix:

  • window.__SENTRY__ and window.Sentry both undefined on strummy.vercel.app
  • DSN absent from all 24 scripts on / and 25 chunks on /sign-in
  • zero client-config chunks in the deployment's build log, while the server config chunk was present

Local production build after the fix:

  • DSN inlined into a client chunk, with replay sample rates, sendDefaultPii, and tracesSampleRate
  • onRouterTransitionStart bundled into 2 chunks
  • lint 0 errors · tsc 0 errors · 290/290 suites, 3797 tests passing

Manual test steps: docs/manual-tests/2026-07-30-sentry-client-instrumentation.html

⚠️ Heads-up before merging

Two things found while verifying, both unrelated to this fix but worth knowing:

  1. main deploys straight to production. The live deployment carries the strummy-git-main-… alias and no production branch exists. Merging this ships to real users immediately — there is no staging gate.
  2. Preview deployments are disabled. vercel.json's ignoreCommand cancels every non-production build after a few seconds, so strummy-preview.vercel.app is stale and cannot be used to check a change first.

CLAUDE.md claimed the opposite on both counts and is corrected here. Auto-merge was deliberately not armed given point 1 — the merge is yours to trigger.

Not covered

Server-side delivery is verified by construction (config compiles in, instrumentation.ts registers it, ingest endpoint confirmed reachable) rather than by watching a real app error arrive. The available Sentry token is project:releases-scoped and cannot read events. An event:read token would close that gap.

Also: the Sentry quota impact of replay plus 10% tracing on live traffic is not measured here.

Obsidian vault not yet updated for this task — follow-up from the Mac.


Full Changelog: v0.161.1...v0.161.2