iOS: Session Replay network-detail capture breaks requests on sentry-cocoa 9.26.0 (Spaceflight E2E regression)

[antonis]

Summary

After bumping sentry-cocoa 9.24.0 → 9.26.0 (#6409), the iOS E2E flow captureSpaceflightNewsScreenTransaction.test.ios.auto began failing deterministically on main and every PR. The flow fails at No visible element found: "Load More Articles" because the article fetch never completes, so the list never renders.

Root cause is in sentry-cocoa 9.26.0, not in RN JS/bridge code: with 9.26.0, an outbound URLSession request to a URL on the Session Replay network-detail allow-list (with body capture enabled) does not complete. This is a functional networking regression, not just telemetry loss.

Why this matters (user impact)

Any app on sentry-cocoa 9.26.0 using Session Replay with networkDetailAllowUrls + networkCaptureBodies will have its requests to those hosts broken. Bounded to allow-listed network-detail URLs; other traffic is unaffected. In @sentry/react-native this surfaces on iOS because the native SDK performs the URLSession instrumentation.

Evidence — three-way E2E bisect (single variable each)

The sample's mobileReplayIntegration in samples/react-native/src/App.tsx configures network-detail capture for exactly the failing host:

Sentry.mobileReplayIntegration({
  networkDetailAllowUrls: ['https://api.spaceflightnewsapi.net'],
  networkCaptureBodies: true,
})

sentry-cocoa	Replay network-detail capture	Spaceflight iOS flow	CI run
9.26.0	on	❌ red (4/4 deterministic)	32713642451
9.24.0	on	✅ green	32722276675
9.26.0	off	✅ green	32725506585

Two independent single-variable flips each turn it green → the trigger is 9.26.0's Session Replay network-detail path. It is the only iOS flow making a real external HTTP request, and the only one that failed; all other iOS flows passed in every run.

Suspected upstream cause (to pass to sentry-cocoa)

getsentry/sentry-cocoa#8497 — "Prevent Session Replay network-detail breadcrumbs from blocking URLSession cancellation on the task monitor" — the only 9.26.0 change touching both the network-detail path and URLSession lifecycle.

Ruled out: getsentry/sentry-cocoa#8650 (trace-header copy-and-replace setter) — not gated on replay network-detail, so disabling network-detail would not have fixed it. Last-known-good is 9.24.0 (9.25.0 shipped no networking changes per the cocoa changelog).

Verification for the cocoa team: revert #8497 on a 9.26.0 build (or bisect 9.25.0→9.26.0) against the repro below.

Reproduction

1. @sentry/react-native on iOS with sentry-cocoa 9.26.0, Session Replay enabled.
2. Configure mobileReplayIntegration with networkDetailAllowUrls: ['<host>'] and networkCaptureBodies: true.
3. From the app, issue a GET to a URL on that host (e.g. https://api.spaceflightnewsapi.net/v4/articles).
4. Observe: the request does not complete; the response body never reaches the app. Deterministic.

Current state / workaround

• Interim options: hold the RN cocoa pin at 9.24.0, or (for users) disable networkCaptureBodies / drop affected hosts from networkDetailAllowUrls on 9.26.0.
• A proof branch demonstrating the third bisect row (removes the two options from the sample; iOS E2E green on 9.26.0) was used to isolate this and has been closed — it was a reproduction, not a merge candidate.

Next steps

• File/track the upstream sentry-cocoa issue (suspected #8497) — this ticket is the reference.
• Once cocoa ships the fix, re-apply the 9.26.0 bump and restore the network-detail options in the sample.
• Watch for cold-start flakiness on re-land and re-add a readiness gate if needed.

[linear-code]

RN-741