Any object href with a concrete pathname (e.g. router.push({ pathname: '/users/42' })) is always assigned concretePathname: false in parseHref, so safePathname and safeRouteName at lines 152–153 always resolve to the raw pathname, exposing it in spans and breadcrumbs even when sendDefaultPii is false.

The PR's core feature — attributing idle navigation spans back to the Expo Router call via navigation.method — is exercised in expoRouter.test.ts only for the setter side; no test in reactnavigation.test.ts (or anywhere else) verifies that reactnavigation.ts actually reads and applies the pending value to the resulting span.

Also found at:

• packages/core/src/js/tracing/reactnavigation.ts:33
• packages/core/src/js/tracing/reactnavigation.ts:455

In parseHref, every object href unconditionally sets concretePathname: false, so { pathname: '/users/42' } is treated as a structural template — its pathname is included in breadcrumbs and spans (data.pathname, span name) even when sendDefaultPii is false. Only string hrefs are gated.

The test 'returns the router unchanged if prefetch method does not exist' passes only because wrapped === router is a same-reference check — but with this change router.push is now replaced with a wrapped function and __sentryWrapped is set, so the router is mutated. The test neither verifies that push was wrapped nor catches any regression in that path.

Consider moving startInactiveSpan (line 177) inside the try block so that a thrown exception clears the pending navigation state and prevents it from incorrectly attributing the next idle navigation span.

setPendingExpoRouterNavigation is set on every successful navigation call but is only consumed when React Navigation fires a state-change event; if the navigation is a no-op (e.g. already at the target route), the stale value persists and the next unrelated navigation's idle span will inherit the wrong navigation.method attribute.

Also found at:

• packages/core/src/js/tracing/reactnavigation.ts:455-458