When Android triggers an Activity restart (isAppRestart = true), consumePendingExpoRouterNavigation() is called unconditionally, and because the downstream if (pendingExpoRouter && latestNavigationSpan) guard has no !isAppRestart check, a restart span can be incorrectly attributed navigation.method from an unrelated prior Expo Router call.

The test at line 51 passes { push: jest.fn() } and asserts expect(wrapped).toBe(router), with a name implying the router is left untouched when prefetch is absent. After this PR, wrapExpoRouter unconditionally wraps push (as well as replace, navigate, back, dismiss) in place, so router.push IS now a different function reference than what was passed in. The assertion still passes only because wrapExpoRouter mutates and returns the same object — reference equality is preserved while the contract implied by the test name (push unchanged) is not. Consider renaming the test and asserting on the method reference (e.g. expect(wrapped.push).toBe(originalPush) — which will fail and reveal the new behavior), or replace this case with one that uses a router lacking any known method (similar to the existing 'returns the router unchanged if no known methods exist' test).

The dismiss test verifies the span and breadcrumb but never asserts consumePendingExpoRouterNavigation(), so the key setPendingExpoRouterNavigation hand-off (the main new mechanism described in the PR) is not verified for dismiss, unlike the equivalent back test which does assert it.

In wrapNavigationMethod (line 170–191 of the file), setPendingExpoRouterNavigation is called before startInactiveSpan, but only the original.apply call is inside the try/catch that invokes clearPendingExpoRouterNavigation on error. If startInactiveSpan throws, the pending is set and never cleared, so the next unrelated idle navigation span will be incorrectly tagged with a stale navigation.method.

Also found at:

• packages/core/test/tracing/expoRouter.test.ts:431-438
• packages/core/test/tracing/expoRouter.test.ts:13-16

If back() or dismiss() returns normally without throwing but does NOT trigger a React Navigation __unsafe_action__ dispatch (e.g. back() called on an empty navigation stack), the pending value set by setPendingExpoRouterNavigation is never consumed — only the catch path calls clearPendingExpoRouterNavigation(). A subsequent unrelated React Navigation dispatch (e.g. a deep-link or programmatic navigation outside the wrapped API) will then consume the stale pending and tag its idle navigation span with the wrong navigation.method.