Wrong data type for doubles with integer-like values

[craxal]

If an entity in a table has a property with an integer-like double value (for example, 123.0), the value is incorrectly interpreted to be an Int32 value whenever entities are queried from the table. This includes listing tables in the explorer, export, and table copy.

This can lead to failures in table copy or import, because some integer-like double values exceed the range of Int32.

[craxal]

The root of the problem lies in the Azure client library. The service returns double values as an unannotated numeral with a decimal for doubles (such as 123.0). The client library uses the built-in JavaScript JSON parser, which eliminates the tell-tale ".0" and thus leads to an incorrect assumption that the value is an Int32, even when the value lies outside the range of an Int32 (Int64 values are sent as annotated JSON strings).

Fixing this isn't trivial, as it requires either a custom JSON parser or some pipeline policy to scan the payload before parsing. It would be easier if the service sent an annotated value instead.

See Azure/azure-sdk-for-js#19899.

[craxal]

A possible workaround is to apply a custom pipeline policy that inserts the expected data type for Double values before the response body gets parsed.

[craxal]

Workaround described as above is sufficient for the time being. I'm keeping this issue open for now, as a solution from the platform or SDK is preferable.

[craxal]

Since this is not likely to be fixed in the library or service anytime soon, I'm going to close this issue, but I'll keep an eye on the client library issue.