fix(replay): Check captureReplay return value in iOS bridge#6008
Open
fix(replay): Check captureReplay return value in iOS bridge#6008
Conversation
The iOS bridge was calling `[PrivateSentrySDKOnly captureReplay]` which is void and discards the BOOL result from the underlying `SentrySessionReplayIntegration.captureReplay()`. It then always returned the replay ID via `getReplayId`, even when the capture actually failed (e.g., replay display link not running). This caused the JS side to attach a `replay_id` to error events pointing to replay data that was never captured and sent. Now we call the integration's `captureReplay()` directly to get the BOOL return value. The bridge only returns a replay ID when capture succeeds. When capture fails, it returns nil, letting the JS fallback logic handle it correctly. Fixes #5074 Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Contributor
Semver Impact of This PR⚪ None (no version bump detected) 📋 Changelog PreviewThis is how your changes will appear in the changelog.
🤖 This preview updates automatically when you update the PR. |
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Addresses review feedback: if getReplayIntegration selector isn't found on PrivateSentrySDKOnly (e.g., future Cocoa SDK changes), fall back to the old void captureReplay call to avoid silently breaking replay capture. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
There was a problem hiding this comment.
✅ Bugbot reviewed your changes and found no new issues!
Comment @cursor review or bugbot run to trigger another review on this PR
Reviewed by Cursor Bugbot for commit 49737b4. Configure here.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
…turn-value # Conflicts: # CHANGELOG.md
Contributor
iOS (legacy) Performance metrics 🚀
|
| Revision | Plain | With Sentry | Diff |
|---|---|---|---|
| 3817909+dirty | 1183.90 ms | 1187.50 ms | 3.60 ms |
| 3ce5254+dirty | 1219.93 ms | 1221.90 ms | 1.96 ms |
| 04207c4+dirty | 1191.27 ms | 1189.78 ms | -1.48 ms |
| 7ac3378+dirty | 1213.37 ms | 1218.15 ms | 4.78 ms |
| 5c1e987+dirty | 1204.30 ms | 1222.15 ms | 17.85 ms |
| 0d9949d+dirty | 1211.38 ms | 1219.67 ms | 8.29 ms |
| 4953e94+dirty | 1212.06 ms | 1214.83 ms | 2.77 ms |
| df5d108+dirty | 1225.90 ms | 1220.14 ms | -5.76 ms |
| a50b33d+dirty | 1197.74 ms | 1197.17 ms | -0.57 ms |
| 3d377b5+dirty | 1218.48 ms | 1219.51 ms | 1.03 ms |
App size
| Revision | Plain | With Sentry | Diff |
|---|---|---|---|
| 3817909+dirty | 3.38 MiB | 4.73 MiB | 1.35 MiB |
| 3ce5254+dirty | 3.38 MiB | 4.76 MiB | 1.38 MiB |
| 04207c4+dirty | 3.38 MiB | 4.76 MiB | 1.38 MiB |
| 7ac3378+dirty | 3.38 MiB | 4.76 MiB | 1.38 MiB |
| 5c1e987+dirty | 3.38 MiB | 4.73 MiB | 1.35 MiB |
| 0d9949d+dirty | 3.38 MiB | 4.76 MiB | 1.38 MiB |
| 4953e94+dirty | 3.38 MiB | 4.73 MiB | 1.35 MiB |
| df5d108+dirty | 3.38 MiB | 4.73 MiB | 1.35 MiB |
| a50b33d+dirty | 3.38 MiB | 4.73 MiB | 1.35 MiB |
| 3d377b5+dirty | 3.38 MiB | 4.76 MiB | 1.38 MiB |
📲 Install BuildsAndroid
|
Contributor
iOS (new) Performance metrics 🚀
|
| Revision | Plain | With Sentry | Diff |
|---|---|---|---|
| 3817909+dirty | 1210.76 ms | 1215.64 ms | 4.89 ms |
| 3ce5254+dirty | 1217.70 ms | 1224.69 ms | 6.99 ms |
| 04207c4+dirty | 1228.55 ms | 1226.04 ms | -2.51 ms |
| 7ac3378+dirty | 1202.35 ms | 1198.31 ms | -4.04 ms |
| 5c1e987+dirty | 1208.43 ms | 1220.72 ms | 12.29 ms |
| 0d9949d+dirty | 1203.94 ms | 1202.27 ms | -1.67 ms |
| 4953e94+dirty | 1217.41 ms | 1223.53 ms | 6.12 ms |
| df5d108+dirty | 1207.34 ms | 1210.50 ms | 3.16 ms |
| a50b33d+dirty | 1207.11 ms | 1212.10 ms | 5.00 ms |
| 3d377b5+dirty | 1201.55 ms | 1201.80 ms | 0.25 ms |
App size
| Revision | Plain | With Sentry | Diff |
|---|---|---|---|
| 3817909+dirty | 3.38 MiB | 4.73 MiB | 1.35 MiB |
| 3ce5254+dirty | 3.38 MiB | 4.76 MiB | 1.38 MiB |
| 04207c4+dirty | 3.38 MiB | 4.76 MiB | 1.38 MiB |
| 7ac3378+dirty | 3.38 MiB | 4.76 MiB | 1.38 MiB |
| 5c1e987+dirty | 3.38 MiB | 4.73 MiB | 1.35 MiB |
| 0d9949d+dirty | 3.38 MiB | 4.76 MiB | 1.38 MiB |
| 4953e94+dirty | 3.38 MiB | 4.73 MiB | 1.35 MiB |
| df5d108+dirty | 3.38 MiB | 4.73 MiB | 1.35 MiB |
| a50b33d+dirty | 3.38 MiB | 4.73 MiB | 1.35 MiB |
| 3d377b5+dirty | 3.38 MiB | 4.76 MiB | 1.38 MiB |
The new captureReplayWithReturnValue method is declared in RNSentry+Test.h but this header wasn't imported by RNSentryTests.m, causing iOS CI to fail with "no known class method for selector 'captureReplayWithReturnValue'". Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
…y/sentry-react-native into fix/replay-capture-return-value
Addresses review feedback: the fallback path in captureReplayWithReturnValue was calling PrivateSentrySDKOnly methods outside the @Try block. If these calls throw, the exception would propagate up to the bridge and leave the JS promise unresolved. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit 1cdb266. Configure here.
clang-format was splitting @Try into "@" and "try {" on separate lines in the fallback path. While clang accepts this, it's unusual and breaks grep discoverability. Wrapped with clang-format off/on pragmas to preserve single-line formatting. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.

📢 Type of change
📜 Description
The iOS bridge was calling
[PrivateSentrySDKOnly captureReplay]which isvoid— it discards theBOOLreturn value from the underlyingSentrySessionReplayIntegration.captureReplay(). It then always returned the replay ID viagetReplayId, even when the capture actually failed (e.g., replay display link not running, session ended, or sampling rejected).This caused the JS side to receive a non-null replay ID, attach it as
replay_idto error events, but the actual replay data was never captured and sent to Sentry. The error event in the dashboard would reference a replay that doesn't exist.What changed
iOS bridge (
RNSentry.mm): AddedcaptureReplayWithReturnValueclass method that calls the integration'scaptureReplay()directly (viamethodForSelector:) to get theBOOLreturn value. The bridge now:YES)nilwhen capture fails (NO), allowing the JS fallback logic inmobilereplay.tsto handle it correctlyHow the Cocoa SDK's
captureReplay()worksPreviously, the bridge ignored this return value and always returned a (potentially stale) replay ID from buffer mode.
💡 Motivation and Context
Fixes #5074
Customers reported that error replay sessions are not uploaded when using
sentry-labelwithreactNavigationIntegration. Investigation revealed that the iOS bridge was masking native-side capture failures by always returning a replay ID. While this alone may not fully explain the customer's issue (the root cause of whycaptureReplay()returnsfalsein their specific scenario needs further investigation), this fix ensures the JS layer gets accurate information about whether replay data was actually captured.💚 How did you test it?
mobilereplay.test.tsverifying behavior whencaptureReplayreturns null vs a replay IDRNSentryTests.mverifyingcaptureReplayWithReturnValuereturnsNOwhen replay is not availablexcodebuild—RNSentry.mmhas no compilation errors)📝 Checklist
sendDefaultPIIis enabled🔮 Next steps
captureReplay()fails in the customer's specific scenario (possibly the display link is paused during a session restart race condition)RNSentryModuleImpl.java), wherecaptureReplayalso doesn't check the return valuedebug: trueand this fix to get native-level[Session Replay]logs showing exactly why capture fails