@sentry/tanstackstart-react 10.55.0 regression: client SDK breaks React re-rendering in production builds (Mantine AppShell stuck) #21770

Summary

Upgrading from @sentry/tanstackstart-react 10.54.0 → 10.55.0 causes a React component to stop re-rendering in response to state changes — but only in a production (minified) build. The dev server and a --mode development build are both unaffected. Bisected to the 10.55.0 release.

In our app it manifests on a Mantine AppShell: the mobile navbar (navbar.collapsed.mobile, driven by a useDisclosure/useState toggle in the header) stops updating. Clicking the hamburger flips the <Burger> to its open icon — so the state did change and that component re-rendered — but the AppShell's collapse <style> (which is derived from the same mobileOpened state via collapsed={{ mobile: !mobileOpened }}) never updates, so the navbar stays at transform: translateX(-100%) and the sidebar never slides in. Effectively the AppShell subtree stops reconciling on a state change that a sibling in the same parent component reacts to correctly.

SDK / environment

• @sentry/tanstackstart-react (+ transitive @sentry/react, @sentry/browser, @sentry/core)
• React 19.2.0
• @tanstack/react-start 1.139.x (Vite + Nitro)
• @mantine/core 8.3.10
• babel-plugin-react-compiler is enabled — but disabling it does not fix the bug.
• Build: vite build (production). Reproduces whether or not Sentry.init() actually runs — it breaks even when the client SDK is only imported but not initialized (no DSN), which suggests module-level/build behavior rather than a runtime integration.

Version bisection (production builds, identical app code)

The regression was introduced in 10.55.0 (each version built with a clean dependency install).

Suspected cause

The 10.55.0 changelog includes feat(tanstackstart-react): Enable component tracking (#21149), which is the most likely candidate for a change that alters how React components are tracked/reconciled. (I have not confirmed the exact mechanism.) Other 10.55 tanstackstart-react changes touching the client/hydration path: #21144 (distributed tracing — connects server↔client traces through hydration) and #21161 (move init to client entry).

What I ruled out

• Not our Sentry.init() config — reproduces even when the SDK is imported but never initialized (no DSN).
• Not the sentryTanstackStart Vite plugin — removing it from the build still reproduces.
• Not the React Compiler — disabling babel-plugin-react-compiler still reproduces.
• Not a hydration mismatch — a benign React Why can't I catch an error directly after install() ? #418 is present on the working 10.54 build too, so it is not the trigger.

Expected vs. actual

• Expected: importing/using the Sentry SDK does not change React's reconciliation; components re-render on state changes in a production build exactly as they do in dev.
• Actual: with 10.55.0+, a Mantine AppShell stops re-rendering on state changes in production builds, while a sibling component (the Burger) driven by the same state still updates.

Workaround

Pinning @sentry/* to 10.54.0 resolves it.

Reproduction

I don't yet have a trimmed-down standalone reproduction — the bisection was done against a large app. I'm happy to put together a minimal Vite + React 19 + Mantine AppShell + @sentry/tanstackstart-react repro if that would help narrow it down; just let me know. Given the SDK is in beta and the precise version bisection points at 10.55.0 (#21149), I wanted to file this early.