Newtonsoft.Json fails to deserialize integer fields after BrainCloud SDK upgrade 5.9.3

LEE JONG GUN

Environment:

Unity (C#)
BrainCloud SDK 5.9.3 (upgraded from 5.9.2)
Issue:
After upgrading to BrainCloud SDK 5.9.3, integer values from cloud code script responses are converted to floats before being passed to the success callback.

Details:

The server-side cloud code script explicitly assigns integer values: var tier = 7;
The server JSON response correctly contains "tier": 7 (integer)
Before SDK 5.9.3: The callback received "tier": 7 (integer, as expected)
After SDK 5.9.3: The callback receives "tier": 7.0 (float, unexpected)
The SDK internally parses and re-serializes the response (likely related to the new JsonParser introduced in 5.9.3??), converting integers to floats in the process
This breaks JsonConvert.DeserializeObject<T>() when the target field is int, throwing: JsonReaderException: Input string '7.0' is not a valid integer
Only affects custom values set in cloud code scripts. BrainCloud's own API values (e.g. rank, score) are not affected.
Expected Behavior:
Integer values from cloud code scripts should remain as integers in the callback response string, same as SDK 5.9.

Steve Jones

Hey @LEE-JONG-GUN Thanks for reaching out,

For us to better support and uncover the issue you are raising, can you provide the appId, and profileId of the user that this occurred on? Can you send this information through the support widget, instead of in the public forum.

This will help us analyze the response and requests and confirm the payload and data being int to float.

Paul Winterhalder

Hi Lee,

We are having difficulties recreating the issue.

Can you post an example JSON response where you are seeing the issue... it may help us to track down what it causing it...

Thanks,

Paul.

Steve Jones

Great news — we've been able to dig into this and have a better picture of what's going on with the client_tier vs. stage_rank behavior.

Here's what we found: stage_rank is defined as an integer in the leaderboard scores response payload, so it comes through cleanly. However, client_tier originates from a Cloud Script Number value, which is treated internally as a double — meaning it can come across with a trailing .0 (e.g., 1.0 instead of 1).

In the past, this was silently handled during serialization/deserialization on the client side. But since the optimized client no longer goes through that process, that .0 is no longer being stripped before the data reaches your callbacks.

In the meantime, here's a quick fix: If you're on version 5.9.3, running the response through a JSON serializer/deserializer — such as JsonParser, Newtonsoft.Json, or Unity's JsonUtility — should clean up that reading path and resolve the issue. There may be a disadvantage in using LitJson.JsonMapper for this case, which presents this as a double, instead of an int like the other object parsers.

We're also actively exploring longer-term solutions to make this more robust on our end, potentially through a configuration option or a fix at the source, so you don't have to work around it manually.

Let us know if you have any questions or run into anything else — happy to help!

LEE JONG GUN

Ok I will try Thank you!