ref(react): Remove lazy route machinery in favour of lazyRouteManifest#19466
ref(react): Remove lazy route machinery in favour of lazyRouteManifest#19466onurtemizkan wants to merge 3 commits intodevelopfrom
lazyRouteManifest#19466Conversation
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
Bugbot Autofix is OFF. To automatically fix reported issues with Cloud Agents, enable Autofix in the Cursor dashboard.
packages/react/src/reactrouter-compat-utils/instrumentation.tsx
Outdated
Show resolved
Hide resolved
size-limit report 📦
|
e7ab1da to
38bf328
Compare
| if (source === 'route') { | ||
| startBrowserTracingNavigationSpan(client, { | ||
| name, | ||
| attributes: { | ||
| [SEMANTIC_ATTRIBUTE_SENTRY_SOURCE]: source, | ||
| [SEMANTIC_ATTRIBUTE_SENTRY_OP]: 'navigation', | ||
| [SEMANTIC_ATTRIBUTE_SENTRY_ORIGIN]: `auto.navigation.react.reactrouter_v${version}`, | ||
| }, | ||
| }); | ||
| } | ||
| } |
There was a problem hiding this comment.
Bug: The manifest fallback path in handleNavigation creates new navigation spans without checking for duplicates, unlike the primary path, leading to multiple spans for a single navigation.
Severity: MEDIUM
Suggested Fix
The manifest fallback path in handleNavigation should replicate the duplicate detection logic from the primary path. Before creating a new span, check activeNavigationSpans for an existing navigation. If one exists, update it. If not, create a new span and add it to the activeNavigationSpans map to ensure it is tracked.
Prompt for AI Agent
Review the code at the location below. A potential bug has been identified by an AI
agent.
Verify if this is a real issue. If it is, propose a fix; if not, explain why it's not
valid.
Location: packages/react/src/reactrouter-compat-utils/instrumentation.tsx#L920-L947
Potential issue: When `handleNavigation` is called multiple times while `branches` is
null (e.g., during a transition before lazy routes are loaded), the manifest fallback
logic is triggered. This path creates a new navigation span via
`startBrowserTracingNavigationSpan` on each invocation. Unlike the primary path, it does
not check the `activeNavigationSpans` map for existing navigations or add the new span
to it. This results in multiple untracked spans for the same logical navigation,
bypassing deduplication and potentially causing a memory leak.
Following up on #19086
This removes the lazy route machinery (
patchSpanEnd,trackLazyRouteLoad,createDeferredLazyRoutePromise,pendingLazyRouteLoads,deferredLazyRouteResolvers,shouldUpdateWildcardSpanName,tryUpdateSpanNameBeforeEnd, etc.) that was previously used to handle parameterized route naming for lazy routes.The series of fixes for this over time (#17867, #17962, #18098, #18155, #18346, #18881, #18898) added increasingly complex race condition handling, deferred promise mechanisms, and span end patching, all trying to ensure correct transaction names when lazy routes hadn't loaded yet. With
lazyRouteManifestintroduced in #19086, we no longer need any of this. The manifest provides the parameterized route name upfront, without needing to wait for route resolution.Removed:
patchSpanEndand the entirespan.end()monkey-patching mechanismtrackLazyRouteLoad/pendingLazyRouteLoadspromise trackingcreateDeferredLazyRoutePromise/resolveDeferredLazyRoutePromisedeferred resolutionshouldUpdateWildcardSpanName/tryUpdateSpanNameBeforeEndwildcard upgrade logic__sentry_may_have_lazy_routes__span flaghandleNavigationandupdatePageloadTransactionAgnosticDataRouteMatchtype import (only used for the removed matches parameter)lazyRouteTimeoutis deprecated with a runtime warning, pointing users tolazyRouteManifest.The
updatePageloadTransactionretains a manifest fallback for the case wherematchRoutesreturns no branches during initial pageload (lazy routes not yet loaded).handleNavigationdoesn't need this as React Router only updatesstate.locationwhen navigation completes (idle), so routes are already resolved.