fix(react): improve handling of routes nested under path="/" #14821

mjq · 2024-12-20T21:37:17Z

We noticed this in Sentry's /issues/:groupId/ route, which uses SDK v8.43.0. The full route tree is complex, but the relevant parts are:

<Route path="/" element={<div>root</div>}>
  <Route path="/issues/:groupId/" element={<div>issues group</div>}>
    <Route index element={<div>index</div>} />
  </Route>
</Route>

If you navigate to e.g. /issues/123 (no trailing slash), the recorded transaction name is //issues/:groupId/ (notice the double slash). This looks messy but doesn't have too much of a consequence.

The worse issue is when you navigate to e.g. /issues/123/ (with trailing slash), the transaction name is /issues/123/ - it is not parameterized. This breaks transaction grouping. On the master and develop branch of the SDK, the transaction name is recorded as /. This causes the transactions to be grouped incorrectly with the root, as well as any other routes nested under a route with path="/".

(Thanks @JoshFerge for noticing the bad data in Sentry! 🙌)

This commit fixes both of these issues and passes both the new tests (which reproduce the above issues) and all existing tests, but I don't trust my changes.

I effectively revert a change from #14304 where

if (basename + branch.pathname === location.pathname) {

became

if (location.pathname.endsWith(basename + branch.pathname)) {

This is the change that caused the difference in results between SDK versions. This will always match when basename is empty, branch.pathname is /, and location.pathname ends with / - in other words, if you have a parent route with path="/", every request ending in a slash will match it instead of the more specific child route. (Depending on how often this kind of Route nesting happens in the wild, this could be a wide regression in transaction names.) But, no tests failed from the removal of endsWith, which makes me worried that there's some necessary behaviour that isn't covered and would be broken by this fix. @onurtemizkan can you give some context into that change? Thanks!

We noticed this in Sentry's `/issues/:groupId/` route, which uses SDK v8.43.0. The full route tree is complex, but the relevent parts are: ```js <Route path="/" element={<div>root</div>}> <Route path="/issues/:groupId/" element={<div>issues group</div>}> <Route index element={<div>index</div>} /> </Route> </Route> ``` If you navigate to e.g. `/issues/123`, the recorded transaction name is `//issues/:groupId/` (notice the double slash). This is messy but doesn't have too much of a consequence. The worse issue is when you navigate to e.g. `/issues/123/` (note the trailing slash), the transaction name is `/issues/123/` - it is not parameterized. This breaks transaction grouping. On the `master` and `develop` branch of the SDK, the transaction name is recorded as `/`. This causes the transactions to be grouped incorrectly with the root, as well as other routes with this structure (nested under a route with path `/`). This commit fixes both of these issues and passes both the new tests (which reproduce the above issues) and all existing tests, but I still don't trust the change. First, `newPath` now always has a leading slash, and I don't know how that interacts with the other path concatenations inside `getNormalizedName`. It feels like dealing with path concatenation should be handled in a more systematic way. Second, I revert a change from 3473447 where ```js if (basename + branch.pathname === location.pathname) { ``` became ``` if (location.pathname.endsWith(basename + branch.pathname)) { ``` This is the change that difference in results between SDK versions. This will always match when `basename` is empty, `branch.pathname` is `/`, and `location.pathname` ends with `/` - in other words, if you have a parent route with `path="/"`, every request ending in a slash will match it instead of the more specific child route. This seems likely to be a wide regression in transaction names. But, no tests failed from this change, which makes me worried that there's some necessary behaviour that isn't covered.

mjq · 2024-12-20T21:52:31Z

packages/react/src/reactrouterv6-compat-utils.tsx

          const newPath = path[0] === '/' || pathBuilder[pathBuilder.length - 1] === '/' ? path : `/${path}`;
-          pathBuilder += newPath;
+          pathBuilder = trimSlash(pathBuilder) + prefixWithSlash(newPath);


Originally I thought to change these lines to

const newPath = prefixWithSlash(path); pathBuilder = trimSlash(pathBuilder) + newPath;

but newPath is used in a different path concatenation further down the method and, even though no tests fail, I didn't want collateral damage. (Tests probably should have failed though - I think the path concatenation in this method could be better handled, and is under-tested.)

I think we can make a refactor/cleanup once we get the tests in a better state.

onurtemizkan

Thanks for the fix @mjq! I think it's safe to merge, and I agree that we need to improve tests to cover as many route declaration patterns as possible.

onurtemizkan · 2024-12-23T14:04:54Z

packages/react/src/reactrouterv6-compat-utils.tsx


          // If the path matches the current location, return the path
-          if (location.pathname.endsWith(basename + branch.pathname)) {
+          if (trimSlash(location.pathname) === trimSlash(basename + branch.pathname)) {


I'd expect this to break descendant routes. But in the final implementation, descendant routes don't end up here. So, I believe it's safe to revert.

onurtemizkan · 2024-12-23T14:06:32Z

packages/react/src/reactrouterv6-compat-utils.tsx

          const newPath = path[0] === '/' || pathBuilder[pathBuilder.length - 1] === '/' ? path : `/${path}`;
-          pathBuilder += newPath;
+          pathBuilder = trimSlash(pathBuilder) + prefixWithSlash(newPath);


I think we can make a refactor/cleanup once we get the tests in a better state.

mjq · 2024-12-23T19:31:46Z

Thanks @onurtemizkan! Going to merge in that case 👍

@JoshFerge

We noticed this in Sentry's `/issues/:groupId/` route, which uses SDK v8.43.0. The full route tree is complex, but the relevant parts are: ```js <Route path="/" element={<div>root</div>}> <Route path="/issues/:groupId/" element={<div>issues group</div>}> <Route index element={<div>index</div>} /> </Route> </Route> ``` If you navigate to e.g. `/issues/123` (no trailing slash), the recorded transaction name is `//issues/:groupId/` (notice the double slash). This looks messy but doesn't have too much of a consequence. The worse issue is when you navigate to e.g. `/issues/123/` (with trailing slash), the transaction name is `/issues/123/` - it is not parameterized. This breaks transaction grouping. On the `master` and `develop` branch of the SDK, the transaction name is recorded as `/`. This causes the transactions to be grouped incorrectly with the root, as well as any other routes nested under a route with `path="/"`. (Thanks @JoshFerge for noticing the bad data in Sentry! 🙌) --- Note that this commit effectively reverts a change from #14304 where ```js if (basename + branch.pathname === location.pathname) { ``` became ```js if (location.pathname.endsWith(basename + branch.pathname)) { ``` This is the change that caused the difference in results between SDK versions. This will always match when `basename` is empty, `branch.pathname` is `/`, and `location.pathname` ends with `/` - in other words, if you have a parent route with `path="/"`, every request ending in a slash will match it instead of the more specific child route. (Depending on how often this kind of `Route` nesting happens in the wild, this could be a wide regression in transaction names.) But, no tests failed from the removal of `endsWith`. @onurtemizkan, who wrote the change in question: > I'd expect this to break descendant routes. But in the final > implementation, descendant routes don't end up here. So, I > believe it's safe to revert.

@JoshFerge

We noticed this in Sentry's `/issues/:groupId/` route, which uses SDK v8.43.0. The full route tree is complex, but the relevant parts are: ```js <Route path="/" element={<div>root</div>}> <Route path="/issues/:groupId/" element={<div>issues group</div>}> <Route index element={<div>index</div>} /> </Route> </Route> ``` If you navigate to e.g. `/issues/123` (no trailing slash), the recorded transaction name is `//issues/:groupId/` (notice the double slash). This looks messy but doesn't have too much of a consequence. The worse issue is when you navigate to e.g. `/issues/123/` (with trailing slash), the transaction name is `/issues/123/` - it is not parameterized. This breaks transaction grouping. On the `master` and `develop` branch of the SDK, the transaction name is recorded as `/`. This causes the transactions to be grouped incorrectly with the root, as well as any other routes nested under a route with `path="/"`. (Thanks @JoshFerge for noticing the bad data in Sentry! 🙌) --- Note that this commit effectively reverts a change from #14304 where ```js if (basename + branch.pathname === location.pathname) { ``` became ```js if (location.pathname.endsWith(basename + branch.pathname)) { ``` This is the change that caused the difference in results between SDK versions. This will always match when `basename` is empty, `branch.pathname` is `/`, and `location.pathname` ends with `/` - in other words, if you have a parent route with `path="/"`, every request ending in a slash will match it instead of the more specific child route. (Depending on how often this kind of `Route` nesting happens in the wild, this could be a wide regression in transaction names.) But, no tests failed from the removal of `endsWith`. @onurtemizkan, who wrote the change in question: > I'd expect this to break descendant routes. But in the final > implementation, descendant routes don't end up here. So, I > believe it's safe to revert.

mjq added 2 commits December 20, 2024 16:05

less intrusive fix for pathBuilder double slash

055b614

mjq commented Dec 20, 2024

View reviewed changes

mjq requested review from onurtemizkan and AbhiPrasad December 20, 2024 21:57

mjq marked this pull request as ready for review December 20, 2024 21:59

onurtemizkan approved these changes Dec 23, 2024

View reviewed changes

duplicate test under describe wrapUseRoutesV6

7c064d0

mjq merged commit 17f7bcd into develop Dec 23, 2024
151 checks passed

mjq deleted the mjq-rr6-txn-names branch December 23, 2024 19:35

malwilley mentioned this pull request Dec 27, 2024

fix(instrumentation): Fix false double leading slashes in transaction names getsentry/sentry#80124

Closed

onurtemizkan mentioned this pull request Jan 3, 2025

fix(v8/react): Improve handling of routes nested under path="/" #14897

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

fix(react): improve handling of routes nested under path="/" #14821

fix(react): improve handling of routes nested under path="/" #14821

mjq commented Dec 20, 2024 •

edited

Loading

mjq Dec 20, 2024

onurtemizkan Dec 23, 2024

onurtemizkan left a comment

onurtemizkan Dec 23, 2024

onurtemizkan Dec 23, 2024

mjq commented Dec 23, 2024

fix(react): improve handling of routes nested under path="/" #14821

fix(react): improve handling of routes nested under path="/" #14821

Conversation

mjq commented Dec 20, 2024 • edited Loading

mjq Dec 20, 2024

Choose a reason for hiding this comment

onurtemizkan Dec 23, 2024

Choose a reason for hiding this comment

onurtemizkan left a comment

Choose a reason for hiding this comment

onurtemizkan Dec 23, 2024

Choose a reason for hiding this comment

onurtemizkan Dec 23, 2024

Choose a reason for hiding this comment

mjq commented Dec 23, 2024

mjq commented Dec 20, 2024 •

edited

Loading