feat(android): Add nativeStackAndroid support to NativeLinkedErrors#6278
Open
lucas-zimerman wants to merge 4 commits into
Open
feat(android): Add nativeStackAndroid support to NativeLinkedErrors#6278lucas-zimerman wants to merge 4 commits into
lucas-zimerman wants to merge 4 commits into
Conversation
Captures the JVM stack trace attached to rejected native module promises as a linked exception, so the Java cause of a rejected promise is reported alongside the JS error. Co-Authored-By: Claude Sonnet 4.6 <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. |
Contributor
|
… into lz/nativeStackAndroid
Comment on lines
+58
to
+60
| if (nativeStackAndroidException && linkedErrors.length + 1 < limit) { | ||
| linkedErrors.push(nativeStackAndroidException); | ||
| } |
There was a problem hiding this comment.
Bug: The limit check linkedErrors.length + 1 < limit is an off-by-one error. It incorrectly prevents adding the final nativeStackAndroid exception when the cause chain is at maximum depth.
Severity: LOW
Suggested Fix
Change the condition linkedErrors.length + 1 < limit to linkedErrors.length < limit. This will correctly allow adding one more exception, up to the specified limit.
Prompt for AI Agent
Review the code at the location below. A potential bug has been identified by an AI
agent. Verify if this is a real issue. If it is, propose a fix; if not, explain why it's
not valid.
Location: packages/core/src/js/integrations/nativelinkederrors.ts#L58-L60
Potential issue: An off-by-one error exists in the limit check for linked errors. The
condition `linkedErrors.length + 1 < limit` prevents adding the `nativeStackAndroid`
exception when the `cause` chain already contains `limit - 1` items. In this scenario,
the check evaluates to `limit < limit`, which is false, causing the native exception to
be silently dropped even though adding it would not exceed the `limit`. This results in
incomplete error data when the exception chain is exactly at the maximum allowed depth.
Did we get this right? 👍 / 👎 to inform future reviews.
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.
Captures the JVM stack trace attached to rejected native module promises as a linked exception, so the Java cause of a rejected promise is reported alongside the JS error.
📢 Type of change
📜 Description
Android Promise rejections were previously captured by Sentry, but lacked stacktrace on it.
💡 Motivation and Context
To close #3257
💚 How did you test it?
Locally with addition of promise rejection button on sample app
Before
https://sentry-sdks.sentry.io/issues/7547068866

After

https://sentry-sdks.sentry.io/issues/7547000366
📝 Checklist
sendDefaultPIIis enabled🔮 Next steps
Close #3257