[sentry]

This PR addresses a TypeError: Cannot read properties of undefined (reading 'case') occurring on the /charts/catalog/charts/$caseId page.

Root Cause:
During client-side navigation between different chart catalog cases, the ChartsCatalogCaseRoute component would attempt to access data.case immediately after useLoaderData(). Due to the pendingMs: 250 setting on the route, there is a brief window (up to 250ms) where useLoaderData() returns undefined while the new loader data is being fetched. The component was not guarding against this undefined state, leading to a crash.

Solution:
Added a null guard (if (!data) return <ChartsCatalogDetailPending />) to the ChartsCatalogCaseRoute component. This ensures that if useLoaderData() returns undefined during the pending state, the ChartsCatalogDetailPending component is rendered gracefully, preventing the TypeError and providing a better user experience during navigation.

Fixes TANSTACK-COM-4RH

_{This PR was automatically generated by Sentry. You can adjust this setting at any time.}

[cloudflare-workers-and-pages]

Deploying with    Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Preview URL	Updated (UTC)
✅ Deployment successful! View logs	tanstack-com	5ec1265	Commit Preview URL Branch Preview URL	Sep 03 2026, 04:24 AM

[tannerlinsley]

I tried the proposed pendingMs explanation in an isolated browser fixture using the installed Router, pendingMs: 250, a 900ms async loader returning { case: ... }, and a component that reads data.case without a guard. Navigating A to B kept the old case before resolving B; quick A/B/A navigation also completed, with zero undefined-data renders and no browser errors. This does not reproduce the full catalog failure, but it does not support pendingMs alone as the cause. Current catalog loaders also throw notFound for missing results rather than returning undefined. Please include the affected case IDs, browser, deployed revision and navigation sequence or stack details so we can reproduce the actual transition. Keeping this open rather than treating a permanent pending fallback as a verified fix.

[tannerlinsley]

Consolidating the duplicate guard in #1285 here. That report includes a concrete transition worth testing: 40-geojson-map to 39-density-contours, with Sentry issue TANSTACK-COM-4RJ (https://tanstack.sentry.io/issues/7673826876/). Its patch guards the same data.case access but renders null instead of the pending component. I have not tested that exact catalog transition yet. Keeping this report open for the root-cause investigation; closing the duplicate patch does not mean either Sentry incident is resolved.

[tannerlinsley]

Confirmed on the live site now. In the Codex in-app browser, I opened https://tanstack.com/charts/catalog/charts/40-geojson-map, waited for the floor plan page to load, then clicked Point density contours in the catalog sidebar. At 19:53:39 UTC the browser logged TypeError: Cannot read properties of undefined (reading 'case') from charts.catalog.charts._caseId-C4M8FcCZ.js:1:308. No network throttling or example execution was needed. This confirms the actual catalog transition fails even though the isolated loader fixture passed. No further reproduction details are needed to keep this bug open. Next is tracing why this route loses its loader data during that transition, then verifying the fix against the same sequence.

[tannerlinsley]

Narrowed this down with a local production build of main at 1ec8b82. With the default Redact runtime (@tanstack/redact 0.1.4), opening 40-geojson-map and clicking Point density contours reproduces the same undefined case error at charts.catalog.charts._caseId-C4M8FcCZ.js:1:308. The destination eventually renders, but the transition logs the exception.

The same source snapshot built with DISABLE_REDACT=true completed that transition and a quick return transition with no captured browser errors. Both used the full app, production Vite/Cloudflare preview, remote docs, and a disposable local database. No throttling or example execution was needed.

This points the investigation toward the Redact/Router transition interaction. It does not establish which runtime behavior is wrong yet, and I have not changed the app runtime or added the fallback guard. Next is reducing this failing default-runtime case and tracing the loader-data subscription during the transition.

[tannerlinsley]

The trace now shows the case component rendering against the new match with status: pending and no loader data, about 250 ms after navigation starts and before the loader finishes.

In Redact 0.1.4, a child already queued for an update can still run after its parent suspends. I reproduced that separately with a parent and child subscribed to one external store: the parent suspends when data becomes pending, but the queued child still reads the missing data and throws.

An experiment in a temporary copy of Redact redirects already-retained queued children through their Suspense boundary, and defers queued descendants when a boundary is newly captured during that flush. The small reproduction then shows its fallback and recovers when data resolves. The full production catalog also completed 40-geojson-map → 39-density-contours → Filled wind-speed contours, followed by return navigation, with no captured browser errors.

This is not a shipped fix. The runtime change still needs broader regression coverage, including nested boundaries and rejected loads, before it can become a dependency update. No website dependencies or route guards have been changed. Keeping this open while that work is verified.