fix(core): Forward user geo as an object so the native scope keeps it#6309
Open
antonis wants to merge 1 commit into
Open
fix(core): Forward user geo as an object so the native scope keeps it#6309antonis wants to merge 1 commit into
antonis wants to merge 1 commit into
Conversation
antonis
force-pushed
the
fix/user-geo-deserialization
branch
from
24d2176 to
3c73d82
Compare
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. |
Contributor
![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 3c73d82. Configure here.
`NATIVE.setUser` ran every required user key (including `geo`) through `_serializeObject`, which JSON-stringifies non-string values. `geo` therefore crossed the bridge as a JSON string, but the native SDKs deserialize it from a nested map: on Android the `User.Deserializer` threw and the whole user was dropped, on iOS the geo was silently ignored. Forward `geo` as a structured object instead. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
antonis
force-pushed
the
fix/user-geo-deserialization
branch
from
3c73d82 to
db77d32
Compare
antonis
changed the title
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
User
geoset from JS never reached the native scope.NATIVE.setUserbuilds the nativeuserKeysby running every required key through_serializeObject, which JSON-stringifies any non-string value.geois an object, so it crossed the bridge as a string like'{"city":"Berlin"}'. The native SDKs, however, deserializegeofrom a nested map:User.Deserializer, since refactor(android,ios): Use native SDK deserializers for User and Breadcrumb #6261) callsGeo.Deserializer, which throwsIOException: Current token is not an objecton a string → the whole user is discarded.userFrom:) guardsgeowithisKindOfClass:NSDictionary.class, so the string is silently ignored → geo lost (user otherwise kept).This PR forwards
geoas a structured object so both platforms deserialize it correctly. The change is JS-only — the native deserializers already handle a nested map.💡 Motivation and Context
Pre-existing bug surfaced while investigating #6306 (the breadcrumb-timestamp regression is fixed separately in #6308). The JS double-encoding predates #6261; #6261 only changed the Android failure mode (geo lost → whole user dropped).
Coordinates with #6289 (removes the manual iOS geo handling in favour of
initWithDictionary:): both expectgeoas a dictionary, so they are complementary and safe to merge in either order. This PR is the JS-layer half that makes the native geo deserialization actually receive an object.💚 How did you test it?
wrapper.test.tssetUsercases to assertgeois forwarded as an object (full / partial / empty / undefined). Verified they fail against the old stringifying code and pass with the fix.geodeserializes viaUser.Deserializerwhile a JSON-stringgeodrops the user (confirming both the regression and the fix). iOSuserFrom:already accepts a geo dictionary, which is exactly what this PR now sends.📝 Checklist
sendDefaultPIIis enabled🔮 Next steps