Runtime: System.Text.Json changes the data datatype from double to int on serialization

[minato7]

This is an issue found while upgrading to System.Text.Json in Asp.NET Core 3.1. We have two webservices which interact based on Json contract.

When webservice1 based on ASP.NET Core, serializes using System.Text.Json a data with datatype double with value 312.0 is passed to Python webservice, we expect serialization to have double value, but this is not the case with System.Text.Json.

This double value is serialized as int value which is causing our webservice2 to treat it as int value 312 and causing variation in floating point results.

This was working perfectly fine with Newtonsoft.Json, as it treats double value 312.0 on serialization to be 312.0

I have uploaded the repo in this link:
https://github.com/minato7/IssueSystemTextJsonDouble

My assumption is if a contract has double datatype, it should be treated as double upon serialization and if it converts to int datatype this is an unexpected behavior, there should be an option provided to treat this double like FloatParseHandling in Newtonsoft.Json to achieve this behavior in System.Text.Json.

[msftbot[bot]]

Tagging subscribers to this area: @jozkee
Notify danmosemsft if you want to be subscribed.

[weichch]

Some discussion on original SO post for cross reference.

[Clockwork-Muse]

.... the first answer on SO points out:

What you have seen is a known portability issue with JSON:

.... so from that point of view there's nothing "wrong" with System.Text.Json...
What the answerer is pointing out is that JSON itself doesn't specify "type" for numbers, that's up to the programming language/api.

Ultimately, regardless of whether we adopt this suggestion, you should make your python code resilient in the face of this sort of input, especially if you may have external clients using this API. If your API needs to do math on these numbers, it should be making sure it's deserialized them into the proper types first, not relied on them being formatted in a certain way.

[layomia]

The "G17" standard format is used by serializer when serializing double types. This format omits the decimal point and/or trailing zeros, if they are not required for the data to roundtrip.

Writing the smallest output required to round trip allows (de)serialization to be faster, and is employed by the serializer when when writing instances of other types, e.g. DateTime{Offset}.

[minato7]

The "G17" standard format is used by serializer when serializing double types. This format omits the decimal point and/or trailing zeros, if they are not required for the data to roundtrip.

This information is quite useful to understand what is happening under the hood, I have observed some truncation of double value coming from Python application and I could relate with G17 standard format.

[minato7]

Ultimately, regardless of whether we adopt this suggestion, you should make your python code resilient in the face of this sort of input, especially if you may have external clients using this API.

@Clockwork-Muse Yes, we realized with this migration process to improve our input parsing, although our python web application is an internal microservice, we decided to make it resilient to any type of input.