fix(v8/react): Add support for React Router sub-routes from `handle` (#17277) by onurtemizkan · Pull Request #17433 · getsentry/sentry-javascript

onurtemizkan · 2025-08-20T07:46:07Z

Backports #17277 and (the fix apart from the refactor at #17438) to v8

seer-by-sentry · 2025-08-21T08:04:23Z

+function processResolvedRoutes(resolvedRoutes: RouteObject[], parentRoute?: RouteObject): void {
+ resolvedRoutes.forEach(child => {
+ allRoutes.add(child);
+ // Only check for async handlers if the feature is enabled
+ if (_enableAsyncRouteHandlers) {
+ checkRouteForAsyncHandler(child);
+ }
+ });


Potential bug: The processResolvedRoutes function lacks cycle detection, which can cause infinite recursion and a stack overflow if a route handler returns a circular reference.
Description: The processResolvedRoutes function iterates through resolved routes to check for async handlers. However, it lacks a check to see if a route has already been processed. If an async route handler's result contains a circular reference (e.g., a route that is an ancestor in the routing tree), the function will enter an infinite recursion loop (processResolvedRoutes -> checkRouteForAsyncHandler -> handleAsyncHandlerResult -> processResolvedRoutes). This leads to a stack overflow, crashing the application.
Suggested fix: Add a guard within the forEach loop in processResolvedRoutes to check if a route has already been processed before calling checkRouteForAsyncHandler. This can be done by checking if (!allRoutes.has(child)), mirroring the protective logic found in getChildRoutesRecursively.
_{severity: 0.85, confidence: 0.9}
_{Did we get this right? 👍 / 👎 to inform future reviews.}

seer-by-sentry · 2025-08-21T08:04:25Z

+ for (const key of Object.keys(route.handle)) {
+ const maybeFn = route.handle[key];
+ if (typeof maybeFn === 'function' && !(maybeFn as { __sentry_proxied__?: boolean }).__sentry_proxied__) {
+ route.handle[key] = createAsyncHandlerProxy(maybeFn, route, key);
+ }
+ }


Potential bug: The checkRouteForAsyncHandler function proxies all functions in a route's handle, not just async loaders, causing significant performance overhead due to a logical flaw.
Description: The checkRouteForAsyncHandler function indiscriminately proxies every function found within a route's handle object. The handle object is often used for various purposes, including synchronous utility functions or metadata generators, not just the intended async route loaders. Every call to any of these proxied functions incurs unnecessary overhead from the proxy's apply trap and the subsequent call to handleAsyncHandlerResult. Because this logic is applied recursively to the entire route tree, it can cause significant performance degradation in applications with complex routing.
Suggested fix: Refine the logic in checkRouteForAsyncHandler to only proxy functions that are intended to be async route handlers. This could be achieved by checking for a specific naming convention for the handler key or introducing a mechanism to opt-in specific functions for proxying, rather than proxying all functions by default.
_{severity: 0.7, confidence: 0.95}
_{Did we get this right? 👍 / 👎 to inform future reviews.}

onurtemizkan · 2025-09-01T21:55:15Z

@mydea, @chargome - I also added the fix inside #17438 here. The CI is not picking up this PR, though.

mydea · 2025-09-02T08:50:38Z

v8 is currently not ship-able, because it still uses ubuntu-20.04 runners 😭 need to "fix" that first... basically the same as #17083 for v8 branch

onurtemizkan · 2025-08-20T07:46:07Z

Backports #17277 and (the fix apart from the refactor at #17438) to v8

…7277)

seer-by-sentry · 2025-08-21T08:04:23Z

+function processResolvedRoutes(resolvedRoutes: RouteObject[], parentRoute?: RouteObject): void {
+ resolvedRoutes.forEach(child => {
+ allRoutes.add(child);
+ // Only check for async handlers if the feature is enabled
+ if (_enableAsyncRouteHandlers) {
+ checkRouteForAsyncHandler(child);
+ }
+ });


Potential bug: The processResolvedRoutes function lacks cycle detection, which can cause infinite recursion and a stack overflow if a route handler returns a circular reference.
Description: The processResolvedRoutes function iterates through resolved routes to check for async handlers. However, it lacks a check to see if a route has already been processed. If an async route handler's result contains a circular reference (e.g., a route that is an ancestor in the routing tree), the function will enter an infinite recursion loop (processResolvedRoutes -> checkRouteForAsyncHandler -> handleAsyncHandlerResult -> processResolvedRoutes). This leads to a stack overflow, crashing the application.
Suggested fix: Add a guard within the forEach loop in processResolvedRoutes to check if a route has already been processed before calling checkRouteForAsyncHandler. This can be done by checking if (!allRoutes.has(child)), mirroring the protective logic found in getChildRoutesRecursively.
_{severity: 0.85, confidence: 0.9}
_{Did we get this right? 👍 / 👎 to inform future reviews.}

seer-by-sentry · 2025-08-21T08:04:25Z

+ for (const key of Object.keys(route.handle)) {
+ const maybeFn = route.handle[key];
+ if (typeof maybeFn === 'function' && !(maybeFn as { __sentry_proxied__?: boolean }).__sentry_proxied__) {
+ route.handle[key] = createAsyncHandlerProxy(maybeFn, route, key);
+ }
+ }


Potential bug: The checkRouteForAsyncHandler function proxies all functions in a route's handle, not just async loaders, causing significant performance overhead due to a logical flaw.
Description: The checkRouteForAsyncHandler function indiscriminately proxies every function found within a route's handle object. The handle object is often used for various purposes, including synchronous utility functions or metadata generators, not just the intended async route loaders. Every call to any of these proxied functions incurs unnecessary overhead from the proxy's apply trap and the subsequent call to handleAsyncHandlerResult. Because this logic is applied recursively to the entire route tree, it can cause significant performance degradation in applications with complex routing.
Suggested fix: Refine the logic in checkRouteForAsyncHandler to only proxy functions that are intended to be async route handlers. This could be achieved by checking for a specific naming convention for the handler key or introducing a mechanism to opt-in specific functions for proxying, rather than proxying all functions by default.
_{severity: 0.7, confidence: 0.95}
_{Did we get this right? 👍 / 👎 to inform future reviews.}

onurtemizkan · 2025-09-01T21:55:15Z

@mydea, @chargome - I also added the fix inside #17438 here. The CI is not picking up this PR, though.

mydea · 2025-09-02T08:50:38Z

v8 is currently not ship-able, because it still uses ubuntu-20.04 runners 😭 need to "fix" that first... basically the same as #17083 for v8 branch

onurtemizkan · 2025-08-20T07:46:07Z

Backports #17277 and (the fix apart from the refactor at #17438) to v8

…7277)

seer-by-sentry · 2025-08-21T08:04:23Z

+function processResolvedRoutes(resolvedRoutes: RouteObject[], parentRoute?: RouteObject): void {
+ resolvedRoutes.forEach(child => {
+ allRoutes.add(child);
+ // Only check for async handlers if the feature is enabled
+ if (_enableAsyncRouteHandlers) {
+ checkRouteForAsyncHandler(child);
+ }
+ });


Potential bug: The processResolvedRoutes function lacks cycle detection, which can cause infinite recursion and a stack overflow if a route handler returns a circular reference.
Description: The processResolvedRoutes function iterates through resolved routes to check for async handlers. However, it lacks a check to see if a route has already been processed. If an async route handler's result contains a circular reference (e.g., a route that is an ancestor in the routing tree), the function will enter an infinite recursion loop (processResolvedRoutes -> checkRouteForAsyncHandler -> handleAsyncHandlerResult -> processResolvedRoutes). This leads to a stack overflow, crashing the application.
Suggested fix: Add a guard within the forEach loop in processResolvedRoutes to check if a route has already been processed before calling checkRouteForAsyncHandler. This can be done by checking if (!allRoutes.has(child)), mirroring the protective logic found in getChildRoutesRecursively.
_{severity: 0.85, confidence: 0.9}
_{Did we get this right? 👍 / 👎 to inform future reviews.}

seer-by-sentry · 2025-08-21T08:04:25Z

+ for (const key of Object.keys(route.handle)) {
+ const maybeFn = route.handle[key];
+ if (typeof maybeFn === 'function' && !(maybeFn as { __sentry_proxied__?: boolean }).__sentry_proxied__) {
+ route.handle[key] = createAsyncHandlerProxy(maybeFn, route, key);
+ }
+ }


Potential bug: The checkRouteForAsyncHandler function proxies all functions in a route's handle, not just async loaders, causing significant performance overhead due to a logical flaw.
Description: The checkRouteForAsyncHandler function indiscriminately proxies every function found within a route's handle object. The handle object is often used for various purposes, including synchronous utility functions or metadata generators, not just the intended async route loaders. Every call to any of these proxied functions incurs unnecessary overhead from the proxy's apply trap and the subsequent call to handleAsyncHandlerResult. Because this logic is applied recursively to the entire route tree, it can cause significant performance degradation in applications with complex routing.
Suggested fix: Refine the logic in checkRouteForAsyncHandler to only proxy functions that are intended to be async route handlers. This could be achieved by checking for a specific naming convention for the handler key or introducing a mechanism to opt-in specific functions for proxying, rather than proxying all functions by default.
_{severity: 0.7, confidence: 0.95}
_{Did we get this right? 👍 / 👎 to inform future reviews.}

onurtemizkan · 2025-09-01T21:55:15Z

@mydea, @chargome - I also added the fix inside #17438 here. The CI is not picking up this PR, though.

mydea · 2025-09-02T08:50:38Z

v8 is currently not ship-able, because it still uses ubuntu-20.04 runners 😭 need to "fix" that first... basically the same as #17083 for v8 branch

onurtemizkan · 2025-08-20T07:46:07Z

Backports #17277 and (the fix apart from the refactor at #17438) to v8

…7277)

seer-by-sentry · 2025-08-21T08:04:23Z

+function processResolvedRoutes(resolvedRoutes: RouteObject[], parentRoute?: RouteObject): void {
+ resolvedRoutes.forEach(child => {
+ allRoutes.add(child);
+ // Only check for async handlers if the feature is enabled
+ if (_enableAsyncRouteHandlers) {
+ checkRouteForAsyncHandler(child);
+ }
+ });


Potential bug: The processResolvedRoutes function lacks cycle detection, which can cause infinite recursion and a stack overflow if a route handler returns a circular reference.
Description: The processResolvedRoutes function iterates through resolved routes to check for async handlers. However, it lacks a check to see if a route has already been processed. If an async route handler's result contains a circular reference (e.g., a route that is an ancestor in the routing tree), the function will enter an infinite recursion loop (processResolvedRoutes -> checkRouteForAsyncHandler -> handleAsyncHandlerResult -> processResolvedRoutes). This leads to a stack overflow, crashing the application.
Suggested fix: Add a guard within the forEach loop in processResolvedRoutes to check if a route has already been processed before calling checkRouteForAsyncHandler. This can be done by checking if (!allRoutes.has(child)), mirroring the protective logic found in getChildRoutesRecursively.
_{severity: 0.85, confidence: 0.9}
_{Did we get this right? 👍 / 👎 to inform future reviews.}

seer-by-sentry · 2025-08-21T08:04:25Z

+ for (const key of Object.keys(route.handle)) {
+ const maybeFn = route.handle[key];
+ if (typeof maybeFn === 'function' && !(maybeFn as { __sentry_proxied__?: boolean }).__sentry_proxied__) {
+ route.handle[key] = createAsyncHandlerProxy(maybeFn, route, key);
+ }
+ }


Potential bug: The checkRouteForAsyncHandler function proxies all functions in a route's handle, not just async loaders, causing significant performance overhead due to a logical flaw.
Description: The checkRouteForAsyncHandler function indiscriminately proxies every function found within a route's handle object. The handle object is often used for various purposes, including synchronous utility functions or metadata generators, not just the intended async route loaders. Every call to any of these proxied functions incurs unnecessary overhead from the proxy's apply trap and the subsequent call to handleAsyncHandlerResult. Because this logic is applied recursively to the entire route tree, it can cause significant performance degradation in applications with complex routing.
Suggested fix: Refine the logic in checkRouteForAsyncHandler to only proxy functions that are intended to be async route handlers. This could be achieved by checking for a specific naming convention for the handler key or introducing a mechanism to opt-in specific functions for proxying, rather than proxying all functions by default.
_{severity: 0.7, confidence: 0.95}
_{Did we get this right? 👍 / 👎 to inform future reviews.}

onurtemizkan · 2025-09-01T21:55:15Z

@mydea, @chargome - I also added the fix inside #17438 here. The CI is not picking up this PR, though.

mydea · 2025-09-02T08:50:38Z

v8 is currently not ship-able, because it still uses ubuntu-20.04 runners 😭 need to "fix" that first... basically the same as #17083 for v8 branch

onurtemizkan · 2025-08-20T07:46:07Z

Backports #17277 and (the fix apart from the refactor at #17438) to v8

…7277)

seer-by-sentry · 2025-08-21T08:04:23Z

+function processResolvedRoutes(resolvedRoutes: RouteObject[], parentRoute?: RouteObject): void {
+ resolvedRoutes.forEach(child => {
+ allRoutes.add(child);
+ // Only check for async handlers if the feature is enabled
+ if (_enableAsyncRouteHandlers) {
+ checkRouteForAsyncHandler(child);
+ }
+ });


Potential bug: The processResolvedRoutes function lacks cycle detection, which can cause infinite recursion and a stack overflow if a route handler returns a circular reference.
Description: The processResolvedRoutes function iterates through resolved routes to check for async handlers. However, it lacks a check to see if a route has already been processed. If an async route handler's result contains a circular reference (e.g., a route that is an ancestor in the routing tree), the function will enter an infinite recursion loop (processResolvedRoutes -> checkRouteForAsyncHandler -> handleAsyncHandlerResult -> processResolvedRoutes). This leads to a stack overflow, crashing the application.
Suggested fix: Add a guard within the forEach loop in processResolvedRoutes to check if a route has already been processed before calling checkRouteForAsyncHandler. This can be done by checking if (!allRoutes.has(child)), mirroring the protective logic found in getChildRoutesRecursively.
_{severity: 0.85, confidence: 0.9}
_{Did we get this right? 👍 / 👎 to inform future reviews.}

seer-by-sentry · 2025-08-21T08:04:25Z

+ for (const key of Object.keys(route.handle)) {
+ const maybeFn = route.handle[key];
+ if (typeof maybeFn === 'function' && !(maybeFn as { __sentry_proxied__?: boolean }).__sentry_proxied__) {
+ route.handle[key] = createAsyncHandlerProxy(maybeFn, route, key);
+ }
+ }


Potential bug: The checkRouteForAsyncHandler function proxies all functions in a route's handle, not just async loaders, causing significant performance overhead due to a logical flaw.
Description: The checkRouteForAsyncHandler function indiscriminately proxies every function found within a route's handle object. The handle object is often used for various purposes, including synchronous utility functions or metadata generators, not just the intended async route loaders. Every call to any of these proxied functions incurs unnecessary overhead from the proxy's apply trap and the subsequent call to handleAsyncHandlerResult. Because this logic is applied recursively to the entire route tree, it can cause significant performance degradation in applications with complex routing.
Suggested fix: Refine the logic in checkRouteForAsyncHandler to only proxy functions that are intended to be async route handlers. This could be achieved by checking for a specific naming convention for the handler key or introducing a mechanism to opt-in specific functions for proxying, rather than proxying all functions by default.
_{severity: 0.7, confidence: 0.95}
_{Did we get this right? 👍 / 👎 to inform future reviews.}

onurtemizkan · 2025-09-01T21:55:15Z

@mydea, @chargome - I also added the fix inside #17438 here. The CI is not picking up this PR, though.

mydea · 2025-09-02T08:50:38Z

v8 is currently not ship-able, because it still uses ubuntu-20.04 runners 😭 need to "fix" that first... basically the same as #17083 for v8 branch

onurtemizkan · 2025-08-20T07:46:07Z

Backports #17277 and (the fix apart from the refactor at #17438) to v8

…7277)

seer-by-sentry · 2025-08-21T08:04:23Z

+function processResolvedRoutes(resolvedRoutes: RouteObject[], parentRoute?: RouteObject): void {
+ resolvedRoutes.forEach(child => {
+ allRoutes.add(child);
+ // Only check for async handlers if the feature is enabled
+ if (_enableAsyncRouteHandlers) {
+ checkRouteForAsyncHandler(child);
+ }
+ });


Potential bug: The processResolvedRoutes function lacks cycle detection, which can cause infinite recursion and a stack overflow if a route handler returns a circular reference.
Description: The processResolvedRoutes function iterates through resolved routes to check for async handlers. However, it lacks a check to see if a route has already been processed. If an async route handler's result contains a circular reference (e.g., a route that is an ancestor in the routing tree), the function will enter an infinite recursion loop (processResolvedRoutes -> checkRouteForAsyncHandler -> handleAsyncHandlerResult -> processResolvedRoutes). This leads to a stack overflow, crashing the application.
Suggested fix: Add a guard within the forEach loop in processResolvedRoutes to check if a route has already been processed before calling checkRouteForAsyncHandler. This can be done by checking if (!allRoutes.has(child)), mirroring the protective logic found in getChildRoutesRecursively.
_{severity: 0.85, confidence: 0.9}
_{Did we get this right? 👍 / 👎 to inform future reviews.}

seer-by-sentry · 2025-08-21T08:04:25Z

+ for (const key of Object.keys(route.handle)) {
+ const maybeFn = route.handle[key];
+ if (typeof maybeFn === 'function' && !(maybeFn as { __sentry_proxied__?: boolean }).__sentry_proxied__) {
+ route.handle[key] = createAsyncHandlerProxy(maybeFn, route, key);
+ }
+ }


Potential bug: The checkRouteForAsyncHandler function proxies all functions in a route's handle, not just async loaders, causing significant performance overhead due to a logical flaw.
Description: The checkRouteForAsyncHandler function indiscriminately proxies every function found within a route's handle object. The handle object is often used for various purposes, including synchronous utility functions or metadata generators, not just the intended async route loaders. Every call to any of these proxied functions incurs unnecessary overhead from the proxy's apply trap and the subsequent call to handleAsyncHandlerResult. Because this logic is applied recursively to the entire route tree, it can cause significant performance degradation in applications with complex routing.
Suggested fix: Refine the logic in checkRouteForAsyncHandler to only proxy functions that are intended to be async route handlers. This could be achieved by checking for a specific naming convention for the handler key or introducing a mechanism to opt-in specific functions for proxying, rather than proxying all functions by default.
_{severity: 0.7, confidence: 0.95}
_{Did we get this right? 👍 / 👎 to inform future reviews.}

onurtemizkan · 2025-09-01T21:55:15Z

@mydea, @chargome - I also added the fix inside #17438 here. The CI is not picking up this PR, though.

mydea · 2025-09-02T08:50:38Z

v8 is currently not ship-able, because it still uses ubuntu-20.04 runners 😭 need to "fix" that first... basically the same as #17083 for v8 branch

onurtemizkan · 2025-08-20T07:46:07Z

Backports #17277 and (the fix apart from the refactor at #17438) to v8

…7277)

seer-by-sentry · 2025-08-21T08:04:23Z

+function processResolvedRoutes(resolvedRoutes: RouteObject[], parentRoute?: RouteObject): void {
+ resolvedRoutes.forEach(child => {
+ allRoutes.add(child);
+ // Only check for async handlers if the feature is enabled
+ if (_enableAsyncRouteHandlers) {
+ checkRouteForAsyncHandler(child);
+ }
+ });


Potential bug: The processResolvedRoutes function lacks cycle detection, which can cause infinite recursion and a stack overflow if a route handler returns a circular reference.
Description: The processResolvedRoutes function iterates through resolved routes to check for async handlers. However, it lacks a check to see if a route has already been processed. If an async route handler's result contains a circular reference (e.g., a route that is an ancestor in the routing tree), the function will enter an infinite recursion loop (processResolvedRoutes -> checkRouteForAsyncHandler -> handleAsyncHandlerResult -> processResolvedRoutes). This leads to a stack overflow, crashing the application.
Suggested fix: Add a guard within the forEach loop in processResolvedRoutes to check if a route has already been processed before calling checkRouteForAsyncHandler. This can be done by checking if (!allRoutes.has(child)), mirroring the protective logic found in getChildRoutesRecursively.
_{severity: 0.85, confidence: 0.9}
_{Did we get this right? 👍 / 👎 to inform future reviews.}

seer-by-sentry · 2025-08-21T08:04:25Z

+ for (const key of Object.keys(route.handle)) {
+ const maybeFn = route.handle[key];
+ if (typeof maybeFn === 'function' && !(maybeFn as { __sentry_proxied__?: boolean }).__sentry_proxied__) {
+ route.handle[key] = createAsyncHandlerProxy(maybeFn, route, key);
+ }
+ }


Potential bug: The checkRouteForAsyncHandler function proxies all functions in a route's handle, not just async loaders, causing significant performance overhead due to a logical flaw.
Description: The checkRouteForAsyncHandler function indiscriminately proxies every function found within a route's handle object. The handle object is often used for various purposes, including synchronous utility functions or metadata generators, not just the intended async route loaders. Every call to any of these proxied functions incurs unnecessary overhead from the proxy's apply trap and the subsequent call to handleAsyncHandlerResult. Because this logic is applied recursively to the entire route tree, it can cause significant performance degradation in applications with complex routing.
Suggested fix: Refine the logic in checkRouteForAsyncHandler to only proxy functions that are intended to be async route handlers. This could be achieved by checking for a specific naming convention for the handler key or introducing a mechanism to opt-in specific functions for proxying, rather than proxying all functions by default.
_{severity: 0.7, confidence: 0.95}
_{Did we get this right? 👍 / 👎 to inform future reviews.}

onurtemizkan · 2025-09-01T21:55:15Z

@mydea, @chargome - I also added the fix inside #17438 here. The CI is not picking up this PR, though.

mydea · 2025-09-02T08:50:38Z

v8 is currently not ship-able, because it still uses ubuntu-20.04 runners 😭 need to "fix" that first... basically the same as #17083 for v8 branch

onurtemizkan · 2025-08-20T07:46:07Z

Backports #17277 and (the fix apart from the refactor at #17438) to v8

…7277)

seer-by-sentry · 2025-08-21T08:04:23Z

+function processResolvedRoutes(resolvedRoutes: RouteObject[], parentRoute?: RouteObject): void {
+ resolvedRoutes.forEach(child => {
+ allRoutes.add(child);
+ // Only check for async handlers if the feature is enabled
+ if (_enableAsyncRouteHandlers) {
+ checkRouteForAsyncHandler(child);
+ }
+ });


Potential bug: The processResolvedRoutes function lacks cycle detection, which can cause infinite recursion and a stack overflow if a route handler returns a circular reference.
Description: The processResolvedRoutes function iterates through resolved routes to check for async handlers. However, it lacks a check to see if a route has already been processed. If an async route handler's result contains a circular reference (e.g., a route that is an ancestor in the routing tree), the function will enter an infinite recursion loop (processResolvedRoutes -> checkRouteForAsyncHandler -> handleAsyncHandlerResult -> processResolvedRoutes). This leads to a stack overflow, crashing the application.
Suggested fix: Add a guard within the forEach loop in processResolvedRoutes to check if a route has already been processed before calling checkRouteForAsyncHandler. This can be done by checking if (!allRoutes.has(child)), mirroring the protective logic found in getChildRoutesRecursively.
_{severity: 0.85, confidence: 0.9}
_{Did we get this right? 👍 / 👎 to inform future reviews.}

seer-by-sentry · 2025-08-21T08:04:25Z

+ for (const key of Object.keys(route.handle)) {
+ const maybeFn = route.handle[key];
+ if (typeof maybeFn === 'function' && !(maybeFn as { __sentry_proxied__?: boolean }).__sentry_proxied__) {
+ route.handle[key] = createAsyncHandlerProxy(maybeFn, route, key);
+ }
+ }


Potential bug: The checkRouteForAsyncHandler function proxies all functions in a route's handle, not just async loaders, causing significant performance overhead due to a logical flaw.
Description: The checkRouteForAsyncHandler function indiscriminately proxies every function found within a route's handle object. The handle object is often used for various purposes, including synchronous utility functions or metadata generators, not just the intended async route loaders. Every call to any of these proxied functions incurs unnecessary overhead from the proxy's apply trap and the subsequent call to handleAsyncHandlerResult. Because this logic is applied recursively to the entire route tree, it can cause significant performance degradation in applications with complex routing.
Suggested fix: Refine the logic in checkRouteForAsyncHandler to only proxy functions that are intended to be async route handlers. This could be achieved by checking for a specific naming convention for the handler key or introducing a mechanism to opt-in specific functions for proxying, rather than proxying all functions by default.
_{severity: 0.7, confidence: 0.95}
_{Did we get this right? 👍 / 👎 to inform future reviews.}

onurtemizkan · 2025-09-01T21:55:15Z

@mydea, @chargome - I also added the fix inside #17438 here. The CI is not picking up this PR, though.

mydea · 2025-09-02T08:50:38Z

v8 is currently not ship-able, because it still uses ubuntu-20.04 runners 😭 need to "fix" that first... basically the same as #17083 for v8 branch

onurtemizkan added 2 commits August 20, 2025 08:43

fix(react): Add support for React Router sub-routes fromhandle(#1…
91044d1
…7277)

Lint
156600c

onurtemizkan marked this pull request as ready for review August 21, 2025 07:57

seer-by-sentryBot reviewed Aug 21, 2025
View reviewed changes

onurtemizkan added the ci-skip-cache label Sep 1, 2025

Apply multiple navigations fix
0e2892b

onurtemizkan force-pushed the onur/backport/lazy-routes-fix-to-v8 branch from f8450d2 to 0e2892bCompare September 1, 2025 21:50

onurtemizkan closed this Dec 22, 2025

onurtemizkan deleted the onur/backport/lazy-routes-fix-to-v8 branch December 22, 2025 10:03

onurtemizkan added 2 commits August 20, 2025 08:43

fix(react): Add support for React Router sub-routes fromhandle(#1…
91044d1
…7277)

Lint
156600c

onurtemizkan marked this pull request as ready for review August 21, 2025 07:57

seer-by-sentryBot reviewed Aug 21, 2025
View reviewed changes

onurtemizkan added the ci-skip-cache label Sep 1, 2025

Apply multiple navigations fix
0e2892b

onurtemizkan force-pushed the onur/backport/lazy-routes-fix-to-v8 branch from f8450d2 to 0e2892bCompare September 1, 2025 21:50

onurtemizkan closed this Dec 22, 2025

onurtemizkan deleted the onur/backport/lazy-routes-fix-to-v8 branch December 22, 2025 10:03

onurtemizkan added 2 commits August 20, 2025 08:43

fix(react): Add support for React Router sub-routes fromhandle(#1…
91044d1
…7277)

Lint
156600c

onurtemizkan marked this pull request as ready for review August 21, 2025 07:57

seer-by-sentryBot reviewed Aug 21, 2025
View reviewed changes

onurtemizkan added the ci-skip-cache label Sep 1, 2025

Apply multiple navigations fix
0e2892b

onurtemizkan force-pushed the onur/backport/lazy-routes-fix-to-v8 branch from f8450d2 to 0e2892bCompare September 1, 2025 21:50

onurtemizkan closed this Dec 22, 2025

onurtemizkan deleted the onur/backport/lazy-routes-fix-to-v8 branch December 22, 2025 10:03

onurtemizkan added 2 commits August 20, 2025 08:43

fix(react): Add support for React Router sub-routes fromhandle(#1…
91044d1
…7277)

Lint
156600c

onurtemizkan marked this pull request as ready for review August 21, 2025 07:57

seer-by-sentryBot reviewed Aug 21, 2025
View reviewed changes

onurtemizkan added the ci-skip-cache label Sep 1, 2025

Apply multiple navigations fix
0e2892b

onurtemizkan force-pushed the onur/backport/lazy-routes-fix-to-v8 branch from f8450d2 to 0e2892bCompare September 1, 2025 21:50

onurtemizkan closed this Dec 22, 2025

onurtemizkan deleted the onur/backport/lazy-routes-fix-to-v8 branch December 22, 2025 10:03

onurtemizkan added 2 commits August 20, 2025 08:43

fix(react): Add support for React Router sub-routes fromhandle(#1…
91044d1
…7277)

Lint
156600c

onurtemizkan marked this pull request as ready for review August 21, 2025 07:57

seer-by-sentryBot reviewed Aug 21, 2025
View reviewed changes

onurtemizkan added the ci-skip-cache label Sep 1, 2025

Apply multiple navigations fix
0e2892b

onurtemizkan force-pushed the onur/backport/lazy-routes-fix-to-v8 branch from f8450d2 to 0e2892bCompare September 1, 2025 21:50

onurtemizkan closed this Dec 22, 2025

onurtemizkan deleted the onur/backport/lazy-routes-fix-to-v8 branch December 22, 2025 10:03

onurtemizkan added 2 commits August 20, 2025 08:43

fix(react): Add support for React Router sub-routes fromhandle(#1…
91044d1
…7277)

Lint
156600c

onurtemizkan marked this pull request as ready for review August 21, 2025 07:57

seer-by-sentryBot reviewed Aug 21, 2025
View reviewed changes

onurtemizkan added the ci-skip-cache label Sep 1, 2025

Apply multiple navigations fix
0e2892b

onurtemizkan force-pushed the onur/backport/lazy-routes-fix-to-v8 branch from f8450d2 to 0e2892bCompare September 1, 2025 21:50

onurtemizkan closed this Dec 22, 2025

onurtemizkan deleted the onur/backport/lazy-routes-fix-to-v8 branch December 22, 2025 10:03

onurtemizkan added 2 commits August 20, 2025 08:43

fix(react): Add support for React Router sub-routes fromhandle(#1…
91044d1
…7277)

Lint
156600c

onurtemizkan marked this pull request as ready for review August 21, 2025 07:57

seer-by-sentryBot reviewed Aug 21, 2025
View reviewed changes

onurtemizkan added the ci-skip-cache label Sep 1, 2025

Apply multiple navigations fix
0e2892b

onurtemizkan force-pushed the onur/backport/lazy-routes-fix-to-v8 branch from f8450d2 to 0e2892bCompare September 1, 2025 21:50

onurtemizkan closed this Dec 22, 2025

onurtemizkan deleted the onur/backport/lazy-routes-fix-to-v8 branch December 22, 2025 10:03

onurtemizkan added 2 commits August 20, 2025 08:43

fix(react): Add support for React Router sub-routes fromhandle(#1…
91044d1
…7277)

Lint
156600c

onurtemizkan marked this pull request as ready for review August 21, 2025 07:57

seer-by-sentryBot reviewed Aug 21, 2025
View reviewed changes

onurtemizkan added the ci-skip-cache label Sep 1, 2025

Apply multiple navigations fix
0e2892b

onurtemizkan force-pushed the onur/backport/lazy-routes-fix-to-v8 branch from f8450d2 to 0e2892bCompare September 1, 2025 21:50

onurtemizkan closed this Dec 22, 2025

onurtemizkan deleted the onur/backport/lazy-routes-fix-to-v8 branch December 22, 2025 10:03

Uh oh!

Uh oh!

Conversation

onurtemizkan commented Aug 20, 2025• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

seer-by-sentryBotAug 21, 2025

Choose a reason for hiding this comment

Uh oh!

seer-by-sentryBotAug 21, 2025

Choose a reason for hiding this comment

Uh oh!

onurtemizkan commented Sep 1, 2025

Uh oh!

mydea commented Sep 2, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Uh oh!

Conversation

onurtemizkan commented Aug 20, 2025• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

seer-by-sentryBotAug 21, 2025

Choose a reason for hiding this comment

Uh oh!

seer-by-sentryBotAug 21, 2025

Choose a reason for hiding this comment

Uh oh!

onurtemizkan commented Sep 1, 2025

Uh oh!

mydea commented Sep 2, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Uh oh!

Conversation

onurtemizkan commented Aug 20, 2025• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

seer-by-sentryBotAug 21, 2025

Choose a reason for hiding this comment

Uh oh!

seer-by-sentryBotAug 21, 2025

Choose a reason for hiding this comment

Uh oh!

onurtemizkan commented Sep 1, 2025

Uh oh!

mydea commented Sep 2, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Uh oh!

Conversation

onurtemizkan commented Aug 20, 2025• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

seer-by-sentryBotAug 21, 2025

Choose a reason for hiding this comment

onurtemizkan commented Aug 20, 2025•
edited
Loading

onurtemizkan commented Aug 20, 2025•
edited
Loading

onurtemizkan commented Aug 20, 2025•
edited
Loading

onurtemizkan commented Aug 20, 2025•
edited
Loading

onurtemizkan commented Aug 20, 2025•
edited
Loading