In reactnavigation.ts handleLateDeepLink (line 250), when a warm-open deep link arrives while a previous navigation's idle span is still recording (lastIdleNavSpan not yet ended), the listener tags that unrelated span and returns true, preventing the link from being stored in the pending slot — so the navigation span actually triggered by the deep link never receives the navigation.trigger/deeplink.url attributes. Consider adding a staleness guard (e.g. comparing link.receivedAtMs against the span's start timestamp) before tagging via the listener path.

In reactNavigationIntegration.afterAllSetup, the close handler calls setPendingDeepLinkListener(undefined) without verifying that the currently-registered listener is the one this client installed. pendingDeepLink.ts stores only a single module-level listener. If Sentry.init() is called a second time in the same JS runtime, the new client's afterAllSetup overwrites the listener with its own handleLateDeepLink closure; when the old client is later explicitly closed, its close handler clears whatever is registered — including the new client's listener — so late-arriving deep links stop being attributed to navigation spans for the rest of the session. An identity guard (e.g. only clear if the current listener is this closure) would prevent the cross-client clear.