Fix GSON Double deserialization for Object fields (Issue #489)#500
Open
arnabnandy7 wants to merge 1 commit into
Open
Fix GSON Double deserialization for Object fields (Issue #489)#500arnabnandy7 wants to merge 1 commit into
arnabnandy7 wants to merge 1 commit into
Conversation
- Configured ToNumberPolicy.LONG_OR_DOUBLE strategy on GSON builders in all auto-generated models (via getGson()) and in APIRequest's convertToString. - This ensures numeric values in unstructured/dynamic Object fields (e.g. TargetingAutomation's individual_setting) are deserialized as Long (integers) rather than Double (floats like 1.0). - Added TargetingAutomationTest to verify that integers are serialized correctly without decimal points.
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.
Description
This PR resolves the issue where integer values inside dynamic or untyped
Objectfields (such asTargetingAutomation.individual_settingcontaining"geo": 1) were parsed by Gson asDouble(e.g.1.0). When these models were serialized back to JSON for request parameters, the decimal suffix was preserved (e.g., sending{"geo": 1.0}instead of{"geo": 1}), causing the Meta Graph/Ads API to reject the requests.We resolve this by setting Gson's
ToNumberPolicy.LONG_OR_DOUBLEstrategy on all Gson instances. This ensures integers in untypedObjectmaps and lists are parsed asLong(retaining their integer representation upon serialization) while actual floating point numbers are parsed asDouble.Changes
1. Updated APIRequest Parameter Serialization
convertToString(Object input)inAPIRequest.javato set.setObjectToNumberStrategy(ToNumberPolicy.LONG_OR_DOUBLE)on the inlineGsonBuilderinstances. This prevents integers inside raw Map/List parameter lists from receiving a decimal suffix.2. SDK-wide Model GSON Updates (982 files)
getGson()helper methods, we updated all 982 model classes' builders to use the sameLONG_OR_DOUBLEstrategy. This comprehensively prevents the bug from occurring on any other dynamicObjectfield.3. Added Regression Unit Test
TargetingAutomationTest.javato verify thatTargetingAutomationcorrectly deserializes and serializes untyped settings containing integers without decimal conversion.Verification & Test Results
Test Execution
We compiled the modified classes and ran the newly introduced
TargetingAutomationTestverification suite:Output
The output confirms that the integer value
1is successfully parsed asLongand serialized correctly as1instead of1.0.