fix(tracing): don't create a duplicate navigation span for Expo Router's withAnchor POP_TO bookkeeping dispatch

[Cryptoteep]

📢 Type of change

• Bugfix
• New feature
• Enhancement
• Refactoring

📜 Description

Expo Router issues a second POP_TO dispatch after a navigation with withAnchor: true, purely to stamp initial: false onto the destination it just navigated to (expo-router getNavigationAction: currentParams.initial = !withAnchor). With useDispatchedActionData: true this bookkeeping dispatch started a second idle navigation span for a single user-facing navigation. The spurious span stole in-flight child spans (HTTP, TTID/TTFD) from the real navigation, lingered until childSpanTimeout force-closed it, and shipped as a confusing duplicate transaction with several children in cancelled status.

Simply adding POP_TO to the filtered action list would break tracking of genuine popTo/dismissTo navigations (on React Navigation 7, dismissTo is a POP_TO). Instead this adds two scoped guards, both active only with useDispatchedActionData:

1. Dispatch time — skip a POP_TO whose target route is already focused somewhere on the active route chain (root → leaf, reusing the same traversal as getPathFromState). A genuine popTo targets a route behind the focused one, and __unsafe_action__ fires before state changes are applied (documented in React Navigation's types), so its target is never focused at that point. This also protects the real navigation's in-flight span from being discarded by the "noop transaction" branch when the bookkeeping dispatch arrives before the deferred state-change microtask (reactNavigationIntegration: navigation transaction can be named/attributed for the previous route instead of the destination when using a route override provider (e.g. expoRouterIntegration) #6436).
2. State-change time — a POP_TO span that landed on the same route key (the dispatch-time filter can miss when the payload carries a parent navigator name that matches no focused route) is now discarded instead of being abandoned to run out its idle timeout — unless a pending deep link claimed it, preserving the deep-link-to-current-screen attribution added earlier.

No behavior change when useDispatchedActionData is disabled (default): the action-type attribute is never set there, so both guards are inert.

💡 Motivation and Context

Fixes #6434

💚 How did you test it?

Added 7 unit tests covering: a genuine POP_TO to a different route still creates a named span; the bookkeeping POP_TO (leaf and nested/parent-navigator payload names) creates no span; it does not remove an in-flight navigation span from the scope; a same-route-key POP_TO span is discarded unless a deep link claimed it; and NAVIGATE landing on the same route keeps its current behavior. Full suite: yarn jest test/tracing/reactnavigation.test.ts — 121 passed, plus pendingDeepLink/expoRouterIntegration/idleNavigationSpan/ttid suites green. tsc -p tsconfig.build.json and oxlint/oxfmt clean.

📝 Checklist

• I added tests to verify changes.
• No new PII added or SDK only sends newly added PII if sendDefaultPII is enabled.
• I updated the docs if needed.
• I updated the wizard if needed.
• All tests passing.
• Public API changes reviewed by another Mobile SDK team member or implemented according to the develop docs spec.
• No breaking changes.

🔮 Next steps

If preferred, the same-route-key discard (guard 2) could later be generalized beyond POP_TO, but that would change behavior for same-route NAVIGATE params updates, so it's deliberately left untouched here.

[github-actions]

Semver Impact of This PR

⚪ None (no version bump detected)

📋 Changelog Preview

This is how your changes will appear in the changelog.
Entries from this PR are highlighted with a left border (blockquote style).

---

• fix(tracing): don't create a duplicate navigation span for Expo Router's withAnchor POP_TO bookkeeping dispatch by Cryptoteep in #6472

---

_{🤖 This preview updates automatically when you update the PR.}

[antonis]

Thanks for taking this on. The state change discard (guard 2) keyed on route.key is the right mechanism, and preserving the deep link case is a nice touch.

One issue with guard 1 (the dispatch time isRouteFocused skip): it matches by route name, so it also suppresses a genuine popTo to an earlier same named route in the stack (common in Expo Router with dynamic routes like [id]). Example: stack [Detail(k1), Detail(k2)] focused on k2, then dismissTo the earlier Detail. The target name equals the focused leaf name, so guard 1 skips a real navigation and its transaction is dropped. I confirmed this against the branch: a popTo to an earlier same named route produces 0 transactions instead of 1.

Suggested fix: also require the withAnchor marker on guard 1, since params.initial is only ever set by withAnchor (see expo router getNavigationAction), so genuine popTos never carry it:

const popToParams = (event?.data?.action?.payload as { params?: { initial?: boolean } } | undefined)?.params;
if (
  navigationActionType === 'POP_TO' &&
  targetRouteName &&
  isRouteFocused(targetRouteName) &&
  popToParams?.initial === false
) {
  ...
}

I verified this keeps all current tests green (they already pass initial: false) and still preserves guard 1's protection of in flight spans, while letting real same named popTos through. Guard 2 still backstops any nested case.

A test that fails on the current branch and passes with the change above:

test('popTo an earlier same-named route in the stack still creates a span', async () => {
  client.eventQueue = [];

  mockNavigation.emitWithStateChange(
    { data: { action: { type: 'PUSH', payload: { name: 'Detail' } }, noop: false, stack: undefined } },
    { key: 'detail_2', name: 'Detail' },
  );
  await jest.runOnlyPendingTimersAsync();
  client.eventQueue = [];

  mockNavigation.emitWithStateChange(
    { data: { action: { type: 'POP_TO', payload: { name: 'Detail' } }, noop: false, stack: undefined } },
    { key: 'detail_1', name: 'Detail' },
  );
  await jest.runOnlyPendingTimersAsync();
  await client.flush();

  expect(client.eventQueue.filter(e => e.type === 'transaction' && e.transaction === 'Detail').length).toBe(1);
});

(Add it inside the useDispatchedActionData names spans from action payload describe, which already sets up client/mockNavigation.)