[RUM] TypeError: Cannot read properties of undefined (reading '_nonReactive') in TanStack Router

[dawsontoth]

Summary

Datadog RUM error tracking reports a recurring TypeError inside @tanstack/router-core that has been active since June 2026 and is still occurring in v2.125.4. 1 occurrence was observed in the last 24 hours.

Datadog Error Tracking: https://app.datadoghq.com/error-tracking/issue/3b73dfac-5d74-11f1-9916-da7ad0900002

Error Details

• Type: TypeError
• Message: Cannot read properties of undefined (reading '_nonReactive')
• Location: @tanstack/router-core@1.171.6 → load-matches.js → js()
• First seen: v2.110.2 (2026-06-01)
• Last seen: v2.125.4 (2026-06-29)
• Platform: Browser
• 24h occurrences: 1

Context

This error occurs during route match loading in TanStack Router. The _nonReactive property read on undefined suggests a match or context object is being accessed before it is initialized — likely during navigation to a route that hasn't fully resolved yet, or during concurrent route transitions.

Note: the CLAUDE.md for this repo documents a known TanStack Router upgrade regression (1.133 → 1.170+) where getParentRoute / addChildren mismatches cause route params to be dropped. This error may be related to that class of issue or to a specific route's match state becoming undefined.

Impact

• Ongoing since June 2026
• Non-crash error (handled), but indicates a routing code path with a potential undefined dereference
• Affects users navigating in the app

Suggested Investigation

1. Check if any recently added or modified route has a getParentRoute / addChildren mismatch (see src/router/rootRouteTree.ts and the regression tests in src/router/__tests__/orgUndefinedRepro.test.ts).
2. Reproduce by navigating between routes rapidly or directly deep-linking to routes that involve route matches being loaded.
3. Add a null check or guard around the _nonReactive access in the router's match loading path if the router version allows it; otherwise consider pinning or upgrading @tanstack/router-core.

Labels

bug rum

[dawsontoth]

Investigation — not actionable in Studio code; closing

Dug into this one. Summary: it's a handled, non-crashing race inside TanStack Router's preloader, we're already on the latest published versions, and our router tree is correct. There's no fix we can land in this repo right now without a disproportionate UX cost, so I'm closing as upstream/won't-fix and we can reopen if it escalates.

What the stack actually shows

TypeError: Cannot read properties of undefined (reading '_nonReactive')
  at Hn  (vendor-tanstack) 
  at async Un (vendor-tanstack)
  at async preloadRoute   ← this is the key frame

The error originates from router.preloadRoute, i.e. the preload-on-intent (hover/focus) path, not an actual navigation. _nonReactive is part of router-core's internal store; the read on undefined is a known race where a match is torn down (user moves the pointer / navigates away) while its preload is still in flight. It is reported as handling: handled and is_crash: false — the router swallows preload failures, so there is no user-visible breakage. Frequency is ~1/day.

Why we can't just bump the router

• Installed: @tanstack/react-router@1.170.16 (this is the latest published version on npm) → pulls @tanstack/router-core@1.171.13.
• The error's stack referenced core 1.171.6; last-seen is on core 1.171.13 (our current). So the race is present in the latest core too — upgrading does not fix it, and there's no newer react-router to move to.

Why it isn't the getParentRoute/addChildren class of bug

I verified src/router/rootRouteTree.ts and src/features/clusters/routes.ts: every route's declared getParentRoute matches where it's mounted via addChildren, and the orgUndefinedRepro regression test covers it. This is a different (preload-timing) issue, not route-tree corruption.

Options considered (and why not now)

1. Disable preloading (defaultPreload in src/router/useNewRouter.ts is 'intent'). This would remove the code path but regresses perceived navigation speed for every desktop user — not worth it for a 1/day handled, non-crashing error.
2. Patch router-core via pnpm patch to null-guard the _nonReactive read. Fragile, easy to lose on the next bump, and we'd be guessing at the library's intent.
3. Wait for upstream. Preferred. The race is benign and self-recovering.

Closing as not actionable in our code / upstream. If RUM shows the frequency climbing or it ever flips to a crash, reopen and we'll pin + patch or report upstream with a repro.

[dawsontoth]

Escalation — reopening per the "reopen if it escalates" note

This was closed on 2026-06-29 as an upstream/won't-fix TanStack Router preloader race, at 1 occurrence / 24h, with the note "we can reopen if it escalates." Today's automated RUM review (window ending 2026-07-08) shows it has escalated:

Last 24h: 10 occurrences across 8 distinct sessions (up from 1 occ / 1 session at closure).

7-day daily trend (occurrences / sessions):

Day	Occurrences	Sessions
-0 (last 24h)	10	8
-1	3	3
-2	1	1
-3	3	2
-4	1	1
-5	0	0
-6	8	7

The session spread is the key change — it went from single-session to 8 users in a day, so this is no longer a one-off race for one person.

Stack (unchanged, still TanStack Router match-loading during preload):

TypeError: Cannot read properties of undefined (reading '_nonReactive')
    at Un @ vendor-tanstack-*.js  (router-core match load)
    at async Wn @ vendor-tanstack-*.js
    at async _a.preloadRoute @ vendor-tanstack-*.js

Breakdown (last 24h):

• Browser: Chrome (10/10)
• Views: /$organizationId/$clusterId/ (5), plus .../databases/, .../databases/$databaseName/$tableName/, .../instances/, .../logs/, and a .../sign-in/ — i.e. it fires on preloadRoute (hover/intent preloading) across many routes, not one.

Still handled/non-crashing, but the widening user impact meets the reopen bar. Given the closure rationale (upstream, no cheap fix), the pragmatic next step may be a guard around the preload match-load path or revisiting the pinned @tanstack/router-core version rather than a deep fix.

Reported by automated Datadog RUM review — 2026-07-08.