fix(react): Remove routes from shared set on `<Routes>` unmount by logaretm · Pull Request #22792 · getsentry/sentry-javascript

logaretm · 2026-07-28T22:09:39Z

Removes a <Routes>'s routes from the module-level allRoutes set when it unmounts, so they can't be matched against a later, unrelated navigation.

The set accumulated every route ever mounted and never removed any. Once two independent routers had each been mounted, matchRoutes ran over the union of both, so a navigation into one could pick up a param name from the other and produce a hybrid transaction name like /bar/:fooId instead of /bar/:barId.

I've taken out the route adding logic from the effect we had and added another one so that we can isolate the add/remove to the same effect to avoid relying on refs that can be fidgity in dev/prod and strict modes.

closes#22782

Will backport to v10

linear-code · 2026-07-28T22:09:43Z

JS-3213

…ent routers Adds two independent descendant <SentryRoutes> trees (foo/*, bar/*) and a cross-router client-side navigation. Because allRoutes is a shared module-level set, navigating into the second router picks up the first router's param name, producing the hybrid /bar/:fooId instead of /bar/:barId. This test currently fails, documenting issue #22782.

The module-level `allRoutes` set accumulated every route ever mounted and never removed any, so once two independent routers had each been mounted, `matchRoutes` ran over the union of both and could name a transaction with one router's static segment and another's param (e.g. `/bar/:fooId`). Removing a `<Routes>`'s routes when it unmounts keeps the set to what is currently mounted, so stale routes from an unrelated router can't be matched against a later navigation. Fixes#22782

The previous cleanup added routes only during the mount render pass but removed them on every unmount. Under StrictMode (mount, unmount, remount) the remount skipped the add, leaving the shared set missing routes and breaking descendant name reconstruction in cross-usage scenarios. Add and remove now share one effect lifecycle, so a StrictMode remount re-adds the routes it removed on the intermediate unmount.

…22948) Backport of: #22792

logaretm · 2026-07-28T22:09:39Z

Removes a <Routes>'s routes from the module-level allRoutes set when it unmounts, so they can't be matched against a later, unrelated navigation.

The set accumulated every route ever mounted and never removed any. Once two independent routers had each been mounted, matchRoutes ran over the union of both, so a navigation into one could pick up a param name from the other and produce a hybrid transaction name like /bar/:fooId instead of /bar/:barId.

I've taken out the route adding logic from the effect we had and added another one so that we can isolate the add/remove to the same effect to avoid relying on refs that can be fidgity in dev/prod and strict modes.

closes#22782

Will backport to v10

linear-code · 2026-07-28T22:09:43Z

JS-3213

…ent routers Adds two independent descendant <SentryRoutes> trees (foo/*, bar/*) and a cross-router client-side navigation. Because allRoutes is a shared module-level set, navigating into the second router picks up the first router's param name, producing the hybrid /bar/:fooId instead of /bar/:barId. This test currently fails, documenting issue #22782.

The module-level `allRoutes` set accumulated every route ever mounted and never removed any, so once two independent routers had each been mounted, `matchRoutes` ran over the union of both and could name a transaction with one router's static segment and another's param (e.g. `/bar/:fooId`). Removing a `<Routes>`'s routes when it unmounts keeps the set to what is currently mounted, so stale routes from an unrelated router can't be matched against a later navigation. Fixes#22782

The previous cleanup added routes only during the mount render pass but removed them on every unmount. Under StrictMode (mount, unmount, remount) the remount skipped the add, leaving the shared set missing routes and breaking descendant name reconstruction in cross-usage scenarios. Add and remove now share one effect lifecycle, so a StrictMode remount re-adds the routes it removed on the intermediate unmount.

…22948) Backport of: #22792

logaretm · 2026-07-28T22:09:39Z

Removes a <Routes>'s routes from the module-level allRoutes set when it unmounts, so they can't be matched against a later, unrelated navigation.

The set accumulated every route ever mounted and never removed any. Once two independent routers had each been mounted, matchRoutes ran over the union of both, so a navigation into one could pick up a param name from the other and produce a hybrid transaction name like /bar/:fooId instead of /bar/:barId.

I've taken out the route adding logic from the effect we had and added another one so that we can isolate the add/remove to the same effect to avoid relying on refs that can be fidgity in dev/prod and strict modes.

closes#22782

Will backport to v10

linear-code · 2026-07-28T22:09:43Z

JS-3213

…ent routers Adds two independent descendant <SentryRoutes> trees (foo/*, bar/*) and a cross-router client-side navigation. Because allRoutes is a shared module-level set, navigating into the second router picks up the first router's param name, producing the hybrid /bar/:fooId instead of /bar/:barId. This test currently fails, documenting issue #22782.

The module-level `allRoutes` set accumulated every route ever mounted and never removed any, so once two independent routers had each been mounted, `matchRoutes` ran over the union of both and could name a transaction with one router's static segment and another's param (e.g. `/bar/:fooId`). Removing a `<Routes>`'s routes when it unmounts keeps the set to what is currently mounted, so stale routes from an unrelated router can't be matched against a later navigation. Fixes#22782

The previous cleanup added routes only during the mount render pass but removed them on every unmount. Under StrictMode (mount, unmount, remount) the remount skipped the add, leaving the shared set missing routes and breaking descendant name reconstruction in cross-usage scenarios. Add and remove now share one effect lifecycle, so a StrictMode remount re-adds the routes it removed on the intermediate unmount.

…22948) Backport of: #22792

logaretm · 2026-07-28T22:09:39Z

Removes a <Routes>'s routes from the module-level allRoutes set when it unmounts, so they can't be matched against a later, unrelated navigation.

The set accumulated every route ever mounted and never removed any. Once two independent routers had each been mounted, matchRoutes ran over the union of both, so a navigation into one could pick up a param name from the other and produce a hybrid transaction name like /bar/:fooId instead of /bar/:barId.

I've taken out the route adding logic from the effect we had and added another one so that we can isolate the add/remove to the same effect to avoid relying on refs that can be fidgity in dev/prod and strict modes.

closes#22782

Will backport to v10

linear-code · 2026-07-28T22:09:43Z

JS-3213

…ent routers Adds two independent descendant <SentryRoutes> trees (foo/*, bar/*) and a cross-router client-side navigation. Because allRoutes is a shared module-level set, navigating into the second router picks up the first router's param name, producing the hybrid /bar/:fooId instead of /bar/:barId. This test currently fails, documenting issue #22782.

The module-level `allRoutes` set accumulated every route ever mounted and never removed any, so once two independent routers had each been mounted, `matchRoutes` ran over the union of both and could name a transaction with one router's static segment and another's param (e.g. `/bar/:fooId`). Removing a `<Routes>`'s routes when it unmounts keeps the set to what is currently mounted, so stale routes from an unrelated router can't be matched against a later navigation. Fixes#22782

The previous cleanup added routes only during the mount render pass but removed them on every unmount. Under StrictMode (mount, unmount, remount) the remount skipped the add, leaving the shared set missing routes and breaking descendant name reconstruction in cross-usage scenarios. Add and remove now share one effect lifecycle, so a StrictMode remount re-adds the routes it removed on the intermediate unmount.

…22948) Backport of: #22792

logaretm · 2026-07-28T22:09:39Z

Removes a <Routes>'s routes from the module-level allRoutes set when it unmounts, so they can't be matched against a later, unrelated navigation.

The set accumulated every route ever mounted and never removed any. Once two independent routers had each been mounted, matchRoutes ran over the union of both, so a navigation into one could pick up a param name from the other and produce a hybrid transaction name like /bar/:fooId instead of /bar/:barId.

I've taken out the route adding logic from the effect we had and added another one so that we can isolate the add/remove to the same effect to avoid relying on refs that can be fidgity in dev/prod and strict modes.

closes#22782

Will backport to v10

linear-code · 2026-07-28T22:09:43Z

JS-3213

…ent routers Adds two independent descendant <SentryRoutes> trees (foo/*, bar/*) and a cross-router client-side navigation. Because allRoutes is a shared module-level set, navigating into the second router picks up the first router's param name, producing the hybrid /bar/:fooId instead of /bar/:barId. This test currently fails, documenting issue #22782.

The module-level `allRoutes` set accumulated every route ever mounted and never removed any, so once two independent routers had each been mounted, `matchRoutes` ran over the union of both and could name a transaction with one router's static segment and another's param (e.g. `/bar/:fooId`). Removing a `<Routes>`'s routes when it unmounts keeps the set to what is currently mounted, so stale routes from an unrelated router can't be matched against a later navigation. Fixes#22782

The previous cleanup added routes only during the mount render pass but removed them on every unmount. Under StrictMode (mount, unmount, remount) the remount skipped the add, leaving the shared set missing routes and breaking descendant name reconstruction in cross-usage scenarios. Add and remove now share one effect lifecycle, so a StrictMode remount re-adds the routes it removed on the intermediate unmount.

…22948) Backport of: #22792

logaretm · 2026-07-28T22:09:39Z

Removes a <Routes>'s routes from the module-level allRoutes set when it unmounts, so they can't be matched against a later, unrelated navigation.

The set accumulated every route ever mounted and never removed any. Once two independent routers had each been mounted, matchRoutes ran over the union of both, so a navigation into one could pick up a param name from the other and produce a hybrid transaction name like /bar/:fooId instead of /bar/:barId.

I've taken out the route adding logic from the effect we had and added another one so that we can isolate the add/remove to the same effect to avoid relying on refs that can be fidgity in dev/prod and strict modes.

closes#22782

Will backport to v10

linear-code · 2026-07-28T22:09:43Z

JS-3213

…ent routers Adds two independent descendant <SentryRoutes> trees (foo/*, bar/*) and a cross-router client-side navigation. Because allRoutes is a shared module-level set, navigating into the second router picks up the first router's param name, producing the hybrid /bar/:fooId instead of /bar/:barId. This test currently fails, documenting issue #22782.

The module-level `allRoutes` set accumulated every route ever mounted and never removed any, so once two independent routers had each been mounted, `matchRoutes` ran over the union of both and could name a transaction with one router's static segment and another's param (e.g. `/bar/:fooId`). Removing a `<Routes>`'s routes when it unmounts keeps the set to what is currently mounted, so stale routes from an unrelated router can't be matched against a later navigation. Fixes#22782

The previous cleanup added routes only during the mount render pass but removed them on every unmount. Under StrictMode (mount, unmount, remount) the remount skipped the add, leaving the shared set missing routes and breaking descendant name reconstruction in cross-usage scenarios. Add and remove now share one effect lifecycle, so a StrictMode remount re-adds the routes it removed on the intermediate unmount.

…22948) Backport of: #22792

logaretm · 2026-07-28T22:09:39Z

Removes a <Routes>'s routes from the module-level allRoutes set when it unmounts, so they can't be matched against a later, unrelated navigation.

The set accumulated every route ever mounted and never removed any. Once two independent routers had each been mounted, matchRoutes ran over the union of both, so a navigation into one could pick up a param name from the other and produce a hybrid transaction name like /bar/:fooId instead of /bar/:barId.

I've taken out the route adding logic from the effect we had and added another one so that we can isolate the add/remove to the same effect to avoid relying on refs that can be fidgity in dev/prod and strict modes.

closes#22782

Will backport to v10

linear-code · 2026-07-28T22:09:43Z

JS-3213

…ent routers Adds two independent descendant <SentryRoutes> trees (foo/*, bar/*) and a cross-router client-side navigation. Because allRoutes is a shared module-level set, navigating into the second router picks up the first router's param name, producing the hybrid /bar/:fooId instead of /bar/:barId. This test currently fails, documenting issue #22782.

The module-level `allRoutes` set accumulated every route ever mounted and never removed any, so once two independent routers had each been mounted, `matchRoutes` ran over the union of both and could name a transaction with one router's static segment and another's param (e.g. `/bar/:fooId`). Removing a `<Routes>`'s routes when it unmounts keeps the set to what is currently mounted, so stale routes from an unrelated router can't be matched against a later navigation. Fixes#22782

The previous cleanup added routes only during the mount render pass but removed them on every unmount. Under StrictMode (mount, unmount, remount) the remount skipped the add, leaving the shared set missing routes and breaking descendant name reconstruction in cross-usage scenarios. Add and remove now share one effect lifecycle, so a StrictMode remount re-adds the routes it removed on the intermediate unmount.

…22948) Backport of: #22792

logaretm · 2026-07-28T22:09:39Z

Removes a <Routes>'s routes from the module-level allRoutes set when it unmounts, so they can't be matched against a later, unrelated navigation.

The set accumulated every route ever mounted and never removed any. Once two independent routers had each been mounted, matchRoutes ran over the union of both, so a navigation into one could pick up a param name from the other and produce a hybrid transaction name like /bar/:fooId instead of /bar/:barId.

I've taken out the route adding logic from the effect we had and added another one so that we can isolate the add/remove to the same effect to avoid relying on refs that can be fidgity in dev/prod and strict modes.

closes#22782

Will backport to v10

linear-code · 2026-07-28T22:09:43Z

JS-3213

…ent routers Adds two independent descendant <SentryRoutes> trees (foo/*, bar/*) and a cross-router client-side navigation. Because allRoutes is a shared module-level set, navigating into the second router picks up the first router's param name, producing the hybrid /bar/:fooId instead of /bar/:barId. This test currently fails, documenting issue #22782.

The module-level `allRoutes` set accumulated every route ever mounted and never removed any, so once two independent routers had each been mounted, `matchRoutes` ran over the union of both and could name a transaction with one router's static segment and another's param (e.g. `/bar/:fooId`). Removing a `<Routes>`'s routes when it unmounts keeps the set to what is currently mounted, so stale routes from an unrelated router can't be matched against a later navigation. Fixes#22782

The previous cleanup added routes only during the mount render pass but removed them on every unmount. Under StrictMode (mount, unmount, remount) the remount skipped the add, leaving the shared set missing routes and breaking descendant name reconstruction in cross-usage scenarios. Add and remove now share one effect lifecycle, so a StrictMode remount re-adds the routes it removed on the intermediate unmount.

…22948) Backport of: #22792

logaretm added 2 commits July 29, 2026 08:47

logaretm force-pushed the awad/js-3213-react-router-v6-integration-allroutes-accumulates-across branch from 8771f29 to 1e33054Compare July 29, 2026 12:47

logaretm marked this pull request as ready for review July 29, 2026 15:32

logaretm requested a review from a team as a code owner July 29, 2026 15:32

logaretm requested review from nicohrubec and s1gr1d and removed request for a teamJuly 29, 2026 15:32

nicohrubec approved these changes Jul 30, 2026
View reviewed changes

s1gr1d approved these changes Jul 30, 2026
View reviewed changes

logaretm merged commit fa8babb into developJul 30, 2026
271 checks passed

logaretm deleted the awad/js-3213-react-router-v6-integration-allroutes-accumulates-across branch July 30, 2026 13:17

logaretm mentioned this pull request Aug 3, 2026
fix(v10/react): Remove routes from shared set on <Routes> unmount #22948
Merged

logaretm added a commit that referenced this pull request Aug 4, 2026
fix(v10/react): Remove routes from shared set on<Routes>unmount (#…
988de7f
…22948) Backport of: #22792