LuciferYang opened a new issue, #12598:
URL: https://github.com/apache/gravitino/issues/12598
### Version
main branch
### Describe what's wrong
`JsonUtils.getStatisticValue` maps every integral JSON node to a `long` and
every floating-point node to a `double`. `BigIntegerNode` is integral too, so
`asLong()` wraps values past the 64-bit range around in two's complement.
Out-of-range floating-point literals are already saturated to infinity by the
parser, and the serializer writes a non-finite double back out as the JSON
string `"Infinity"`, so such a value returns as a `StringValue` on the next
round trip.
Neither case reports an error, so a statistic value the client sent is
silently replaced by a different one, with the sign flipped in some cases.
`StatisticsUpdateRequest.validate()` cannot catch this: it only checks for a
null value, and it runs after Jackson has built the map, by which point the
truncated `long` is all that is left.
### Error message and/or stacktrace
No error is reported, and that is the bug. The request returns 200 and the
wrong number is stored.
### How to reproduce
Against main branch:
```
PUT /metalakes/{metalake}/objects/table/{fullName}/statistics
{"updates": {"row-count": 9223372036854775808}}
```
Returns 200. Reading the statistic back yields `-9223372036854775808`.
Measured on jackson-databind 2.15.2, the version this project pins:
| value sent | value stored |
|---|---|
| `9223372036854775807` | `9223372036854775807` |
| `9223372036854775808` | `-9223372036854775808` |
| `-9223372036854775809` | `9223372036854775807` |
| `123456789012345678901234567890` | `-4362896299872285998` |
| `-123456789012345678901234567890` | `4362896299872285998` |
| `1.5E400` | `Infinity`, re-serialized as the JSON string `"Infinity"`,
read back as a `StringValue` |
The same applies to the `/partitions` variant of the endpoint, and to a
value nested inside a list or an object statistic.
### Additional context
`StatisticValue` has no BigInteger or BigDecimal type, so there is no
lossless representation to fall back to. Rejecting the request is the only
correct option.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
