Skip to content

Comments

fix(react): Defer React Router span finalization until lazy routes load#18881

Merged
s1gr1d merged 5 commits intodevelopfrom
onur/defer-lazy-span-finalization
Jan 26, 2026
Merged

fix(react): Defer React Router span finalization until lazy routes load#18881
s1gr1d merged 5 commits intodevelopfrom
onur/defer-lazy-span-finalization

Conversation

@onurtemizkan
Copy link
Collaborator

@onurtemizkan onurtemizkan commented Jan 19, 2026

Following up on #18155 and #18346

Fixes an issue where pageload transactions have incorrect names (URL-based or wildcard-based) when lazy routes load after the span ends due to idle timeout.

This occurs when using patchRoutesOnNavigation for lazy route loading. The idle timeout can fire before lazy routes finish loading, causing the span to end with a wildcard like /slow-fetch/* instead of the parameterized /slow-fetch/:id.

The root cause was that the active span was captured after router creation, making it inaccessible when patchRoutesOnNavigation was called later (span already ended). Also, patchSpanEnd was taking a snapshot of allRoutes, so lazy routes added later wouldn't be visible.

This fix:

  • Captures the active span before router creation and passes it to wrapPatchRoutesOnNavigation
  • Adds a deferred promise mechanism that blocks span finalization until patchRoutesOnNavigation completes
  • Uses the global allRoutes Set directly instead of a snapshot
  • Handles pageload spans in patchRoutesOnNavigation (was only handling navigation before)

@onurtemizkan onurtemizkan force-pushed the onur/defer-lazy-span-finalization branch from c7953b2 to c11361b Compare January 19, 2026 12:18
@github-actions
Copy link
Contributor

github-actions bot commented Jan 19, 2026

size-limit report 📦

Path Size % Change Change
@sentry/browser 25.2 kB - -
@sentry/browser - with treeshaking flags 23.71 kB - -
@sentry/browser (incl. Tracing) 42.02 kB - -
@sentry/browser (incl. Tracing, Profiling) 46.66 kB - -
@sentry/browser (incl. Tracing, Replay) 80.63 kB - -
@sentry/browser (incl. Tracing, Replay) - with treeshaking flags 70.28 kB - -
@sentry/browser (incl. Tracing, Replay with Canvas) 85.32 kB - -
@sentry/browser (incl. Tracing, Replay, Feedback) 97.53 kB - -
@sentry/browser (incl. Feedback) 41.92 kB - -
@sentry/browser (incl. sendFeedback) 29.89 kB - -
@sentry/browser (incl. FeedbackAsync) 34.89 kB - -
@sentry/browser (incl. Metrics) 26.31 kB - -
@sentry/browser (incl. Logs) 26.46 kB - -
@sentry/browser (incl. Metrics & Logs) 27.11 kB - -
@sentry/react 26.93 kB - -
@sentry/react (incl. Tracing) 44.26 kB +0.01% +1 B 🔺
@sentry/vue 29.64 kB - -
@sentry/vue (incl. Tracing) 43.82 kB - -
@sentry/svelte 25.22 kB - -
CDN Bundle 27.78 kB - -
CDN Bundle (incl. Tracing) 42.83 kB - -
CDN Bundle (incl. Tracing, Logs, Metrics) 43.65 kB - -
CDN Bundle (incl. Tracing, Replay) 79.53 kB - -
CDN Bundle (incl. Tracing, Replay, Feedback) 84.97 kB - -
CDN Bundle (incl. Tracing, Replay, Feedback, Logs, Metrics) 85.89 kB - -
CDN Bundle - uncompressed 81.27 kB - -
CDN Bundle (incl. Tracing) - uncompressed 126.81 kB - -
CDN Bundle (incl. Tracing, Logs, Metrics) - uncompressed 129.65 kB - -
CDN Bundle (incl. Tracing, Replay) - uncompressed 243.35 kB - -
CDN Bundle (incl. Tracing, Replay, Feedback) - uncompressed 256.15 kB - -
CDN Bundle (incl. Tracing, Replay, Feedback, Logs, Metrics) - uncompressed 258.96 kB - -
@sentry/nextjs (client) 46.62 kB - -
@sentry/sveltekit (client) 42.39 kB - -
@sentry/node-core 51.9 kB - -
@sentry/node 165.46 kB -0.01% -1 B 🔽
@sentry/node - without tracing 93.66 kB - -
@sentry/aws-serverless 109.16 kB - -

View base workflow run

@onurtemizkan onurtemizkan force-pushed the onur/defer-lazy-span-finalization branch 2 times, most recently from 34ccaca to c47669c Compare January 20, 2026 11:07
@onurtemizkan onurtemizkan marked this pull request as ready for review January 20, 2026 11:10
@onurtemizkan onurtemizkan requested a review from Copilot January 20, 2026 12:15
Copy link
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This PR fixes a critical issue where pageload transactions receive incorrect names (URL-based or wildcard-based) when lazy routes load after the span ends due to idle timeout. The fix introduces a deferred promise mechanism to block span finalization until patchRoutesOnNavigation completes, ensuring lazy-loaded routes are available for proper transaction naming.

Changes:

  • Added deferred promise mechanism that blocks span finalization until lazy routes finish loading via patchRoutesOnNavigation
  • Captured active span before router creation (instead of after) to maintain reference even if span ends before lazy routes load
  • Modified patchSpanEnd to use global allRoutes Set directly instead of a snapshot, allowing visibility of routes added after span starts
  • Extended patchRoutesOnNavigation wrapper to handle both pageload and navigation spans (previously only navigation)

Reviewed changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated 9 comments.

Show a summary per file
File Description
packages/react/src/reactrouter-compat-utils/instrumentation.tsx Core implementation: adds deferred promise mechanism, moves span capture timing, updates patchSpanEnd to use global allRoutes, extends patchRoutesOnNavigation to handle pageload spans
packages/react/test/reactrouter-compat-utils/instrumentation.test.tsx Unit tests verifying allRoutes global set behavior and proper handling of late route additions
dev-packages/e2e-tests/test-applications/react-router-7-lazy-routes/tests/transactions.test.ts E2E regression tests verifying slow lazy routes get parameterized names even with early span end
dev-packages/e2e-tests/test-applications/react-router-7-lazy-routes/src/pages/WildcardLazyRoutes.tsx New test component simulating slow lazy route loading with wildcard routes
dev-packages/e2e-tests/test-applications/react-router-7-lazy-routes/src/index.tsx Router configuration for wildcard lazy route test scenario

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

@onurtemizkan onurtemizkan force-pushed the onur/defer-lazy-span-finalization branch from b578154 to a9ed0f4 Compare January 21, 2026 10:59
Copy link
Member

@chargome chargome left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good but the code for this becomes increasingly difficult to read. We should add a state/mermaid diagram at some point for more clarity on how we do parameterization here

Thanks for fixing!

Comment on lines 841 to 852
for (const route of allRoutes) {
const idMatches = route.id !== undefined && route.id === routeId;
const referenceMatches = route === leafRoute;
const pathMatches =
route.path !== undefined && leafRoute.path !== undefined && route.path === leafRoute.path;

if (idMatches || referenceMatches || pathMatches) {
// Attach children to this parent route
addResolvedRoutesToParent(children, route);
break;
}
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You could use .find() here (fewer bytes in bundle size and readable):

const matchingRoute = allRoutes.find(route => {
  const idMatches = route.id !== undefined && route.id === routeId;
  const referenceMatches = route === leafRoute;
  const pathMatches = route.path !== undefined && leafRoute.path !== undefined && route.path === leafRoute.path;

  return idMatches || referenceMatches || pathMatches;
});

if (matchingRoute) {
  addResolvedRoutesToParent(children, targetRoute);
}

@onurtemizkan
Copy link
Collaborator Author

Looks good but the code for this becomes increasingly difficult to read. We should add a state/mermaid diagram at some point for more clarity on how we do parameterization here

I agree, I'll add a dev-docs with diagrams after we're eventually sure we eliminated all potential edge cases.

@github-actions
Copy link
Contributor

node-overhead report 🧳

Note: This is a synthetic benchmark with a minimal express app and does not necessarily reflect the real-world performance impact in an application.

Scenario Requests/s % of Baseline Prev. Requests/s Change %
GET Baseline 9,387 - 8,944 +5%
GET With Sentry 1,803 19% 1,786 +1%
GET With Sentry (error only) 6,286 67% 6,223 +1%
POST Baseline 1,209 - 1,206 +0%
POST With Sentry 603 50% 597 +1%
POST With Sentry (error only) 1,052 87% 1,064 -1%
MYSQL Baseline 3,311 - 3,304 +0%
MYSQL With Sentry 483 15% 513 -6%
MYSQL With Sentry (error only) 2,726 82% 2,667 +2%

View base workflow run

@s1gr1d s1gr1d merged commit f915139 into develop Jan 26, 2026
211 checks passed
@s1gr1d s1gr1d deleted the onur/defer-lazy-span-finalization branch January 26, 2026 13:53
onurtemizkan added a commit that referenced this pull request Feb 10, 2026
…es (#19086)

This PR will resolve the core reason for the series of fixes / handling
for automatic lazy-route resolution for a while.

Related: #18898,
#18881,
#18346,
#18155,
#18098,
#17962,
#17867,
#17438,
#17277

The core issue we have been trying to tackle is not having access to the
complete route hierarchy when asynchronously loaded lazy routes are
used. React Router provides a route manifest that we can use while
matching parameterized transaction names with routes in all cases except
this lazy-routes pattern.

This problem has been discussed on React Router:
- remix-run/react-router#11113

While this has been
[addressed](remix-run/react-router#11626) for
Remix / React Router (Framework Mode), it's still not available in
Library Mode. The manifest contains the lazily-loaded route, only when
it's navigated to. While waiting for navigation, our transactions can be
dropped for several reasons, such as user behaviour like switching tabs
(`document.hidden` guard), hitting timeouts like `idleTimeout`, and
potentially other reasons. This results in incomplete transaction naming
with leftover wildcards, which caused broken aggregation on the Sentry
dashboard.

The series of attempts to fix this while keeping automatic route
discovery has been prone to race conditions and required special-case
handling of each edge case scenario, also requiring a considerable
amount of internal logic, affecting our readability and performance. At
the end, all failed in giving completely robust and deterministic
results on the customers' side.

This PR proposes a new option: `lazyRouteManifest` specifically for lazy
routes. This will let us have initial information about the route
hierarchy. So we can assign correct parameterized transaction names
without needing to wait for navigated state.

It's a static array of routes in parameterized format (needs to be
maintained by the users on route hierarchy updates) like:

```ts
Sentry.reactRouterV7BrowserTracingIntegration({
  // ...
  enableAsyncRouteHandlers: true
  lazyRouteManifest: [
    '/',
    '/pricing',
    '/features',
    
    '/login',
    '/signup',
    '/forgot-password',
    '/reset-password/:token',
    
    '/org/:orgSlug',
    '/org/:orgSlug/dashboard',
    '/org/:orgSlug/projects',
    '/org/:orgSlug/projects/:projectId',
    '/org/:orgSlug/projects/:projectId/settings',
    '/org/:orgSlug/projects/:projectId/issues',
    '/org/:orgSlug/projects/:projectId/issues/:issueId',
    '/org/:orgSlug/team',
    '/org/:orgSlug/team/:memberId',
    '/org/:orgSlug/settings',
    '/org/:orgSlug/billing',
    
    '/admin',
    '/admin/users',
    '/admin/users/:userId',
    '/admin/orgs',
    '/admin/orgs/:orgId',
  ],
})
```


- This will only be active when `enableAsyncRouteHandlers` is set to
`true`
- To match URLs with given routes, we mimic React Router's own
implementation.
- When this is not provided or fails, it falls back to the current
behaviour
- This manifest is primarily for lazy routes, but the users can also add
their non-lazy routes here for convenience or consistency.
- Also added E2E tests that will fail when (if at some point) React
Router manifests include the lazy routes before navigation, so we'll be
aware and plan depending on that manifest instead.
- We can do a cleanup for the race-condition / edge-case handling part
of the code in a follow-up PR.

Closes #19090 (added automatically)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants