fix(android): Prevent breadcrumb loss from numeric timestamp ClassCastException#6308
Open
antonis wants to merge 2 commits into
Open
fix(android): Prevent breadcrumb loss from numeric timestamp ClassCastException#6308antonis wants to merge 2 commits into
antonis wants to merge 2 commits into
Conversation
…tException The JS SDK stamps `breadcrumb.timestamp` as a number (epoch seconds), which arrives over the bridge as a `Double`. Since 8.14.0 (#6261) the native `Breadcrumb.Deserializer` reads `timestamp` as an ISO-8601 string and threw a `ClassCastException`, discarding every synced breadcrumb on Android so native crash reports lost breadcrumb context. Normalize a numeric `timestamp` to an ISO-8601 string before deserializing. Fixes #6306 Co-Authored-By: Claude Opus 4.8 <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.
Plus 3 more 🤖 This preview updates automatically when you update the PR. |
antonis
commented
Jun 17, 2026
Contributor
Author
|
@sentry review |
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
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 a8c2748. Configure here.
10 tasks
📲 Install BuildsAndroid
|
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
1 participant
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
On Android, every breadcrumb synced from JS to the native scope was being discarded since
8.14.0.The JS SDK stamps
breadcrumb.timestampas a number (epoch seconds), which arrives over the bridge as ajava.lang.Double. Since #6261,RNSentryBreadcrumb.fromMapfeeds the map to the nativeBreadcrumb.Deserializer, which readstimestampviaMapObjectReader.nextDateOrNull→nextStringOrNulland requires an ISO-8601 string. ADoublethrowsClassCastException, the breadcrumb is dropped, and an empty fallback (onlyorigin = "react-native") is returned — so native/tombstone crash reports lose breadcrumb context.This PR normalizes a numeric
timestampto an ISO-8601 string before deserializing, preserving millisecond precision. Existing behavior is unchanged for ISO-string and missing timestamps. iOS is unaffected (Cocoa'sinitWithDictionary:is lenient).💡 Motivation and Context
Fixes #6306. Regression introduced in
8.14.0by #6261 ("Use native SDK deserializers for User and Breadcrumb").💚 How did you test it?
Added
RNSentryBreadcrumbTest.parsesNumericTimestampWithoutDiscardingBreadcrumb, which feeds a numeric timestamp and asserts the breadcrumb survives with its fields and correct timestamp. Verified it fails (messageisnull) without the fix and passes with it. Full Android unit suite green.📝 Checklist
sendDefaultPIIis enabled🔮 Next steps
A follow-up PR will fix a separate, pre-existing issue surfaced during this investigation: user
geois JSON-stringified before crossing the bridge, so the native deserializer drops it (and on Android, the whole user). That fix touches the JS layer and coordinates with #6289.