[seongwon030]

Closes #25638

• If you've added code that should be tested, please add tests.
• Ensure your code lints and the test suite passes (pnpm run lint) & (pnpm run test).
• Link an issue if there is one related to your pull request. If no issue is linked, one will be auto-generated and linked.

location.pathname is percent-encoded, but React Router decodes the pathname before matching (decodePath), so RouteMatch.pathname and pathnameBase are decoded. The React Router instrumentation compared the two with plain string equality, so a route like /clubs/:clubId visited as /clubs/%ED%95%9C%EA%B8%80 never matched and the transaction fell back to the raw URL with source url. Every non-ASCII parameter value became its own transaction name. Descendant routes (<Routes> nested under a /* route) produced the raw URL with source route.

This adds decodePathname, the same segment-wise algorithm as React Router's decodePath, and applies it to both sides of the comparison in getNormalizedName and of the pathnameBase stripping for descendant routes. Decoding both sides keeps percent-encoded basenames and older 6.x routers working: before 6.22.1 matchRoutes matched against the raw pathname or used decodeURI, so there the branch pathname is the side that is still encoded. A value that still looks percent-encoded after one decode (a literal %41) is decoded once more; such values were not parameterized before either.

Validation (in packages/react):

• vitest run on the React Router suites (react-router, reactrouterv6, reactrouter-descendant-routes, reactrouter-cross-usage, reactrouter-compat-utils/*): 276 tests passed, including the new ones
• The new decodePathname, getNormalizedName, rebuildRoutePathFromAllRoutes, v7 pageload/navigation and v6 descendant-route tests fail without the fix
• pnpm run lint clean; oxfmt --check passed on the changed files
• Browser integration tests (Playwright) were not run

[s1gr1d]

Thanks, the looking into this and tests are great!

Instead of decoding, could we compare segment counts? Decoding never changes the number of / segments, so we don't need decodePathname. That also avoids two issues: /clubs/%2541 still doesn't match, because match.pathname gets decoded twice. And descendant routes now pass decoded paths back into matchRoutes, so /clubs/100%25 logs a "could not be decoded" warning.

Your tests already pass with the segment approach. Could you add those two URLs as cases too?

[s1gr1d]

Heads-up: react-router 6.22.1+ already decodes match.pathname, so this decodes it a second time. A literal %41 in a param then doesn't match.