[RoMiRoSSaN]

Fixes #2781

Changes

• IntegerScalar: the range check is exact and includes both bounds. Int.MIN_VALUE is accepted.
• Integer targets (byte, short, int, long, atomic and Optional* wrappers): the conversion is exact. intValue() and casts are replaced with *ValueExact, so overflow and fractions return a GraphQL error.
• Floating-point targets (float, double, OptionalDouble): NaN, Infinity and finite overflow return a GraphQL error. Normal IEEE rounding is kept.
• Input objects (records, POJOs, nested objects, lists): numeric fields are checked before JSON binding. Each field's number type is resolved once, when the schema is built.
• Missing OptionalInt / OptionalLong / OptionalDouble arguments: passed as Optional*.empty() instead of null.
• Unchanged: BigInteger, BigDecimal and the schema.

// before
return bigInteger.intValue();
return (byte) input.intValue();

// after
return bigInteger.intValueExact();
return input instanceof Byte ? input : byteValueExact(input);

Before / after

Java parameter	Input	Before	After
int	2147483648	method receives -2147483648	error
int	-2147483648	error	method receives -2147483648
int	variable 1.5	method receives 1	error
byte	128	method receives -128	error
long	variable 9223372036854775808	method receives -9223372036854775808	error
float	1e39	method receives Infinity	error
record with int field	-99999999999999999999999999999	method receives 1610612737, or an unrelated Unknown Scalar Type error	error naming the field

Example error after the fix:

Validation error (WrongType@[primitiveInt]) : argument 'input' with value 'IntValue{value=2147483648}'
is not a valid 'Int' - SRGQL000014: Expected value to be in the Int range but it was 'IntValue{value=2147483648}'

[phillip-kruger]

The FieldHelper.getArrayType change breaks @NumberFormat on numeric array outputs. See the inline comment. The rest of server/implementation passes locally.

Two behaviour changes that aren't in the description and should go in the release notes:

• Output serialization also goes through the new convertImpl, so a resolver returning NaN or Infinity for a Float field now gets a field error instead of passing the value through.
• A missing OptionalInt/OptionalLong/OptionalDouble argument is now empty() instead of null.

[phillip-kruger]

This breaks @NumberFormat on arrays. For a formatted number the reference keeps className = the number type but graphQLClassName = String. This branch returns the number class, so recursiveTransformArray hits the "component type already matches" shortcut and never applies the format:

@Query @NumberFormat("#,##0.00") public Double[] boxedDoubles() { return new Double[]{1234.5, 2.0}; }
@Query @NumberFormat("#,##0.00") public int[] primitiveInts() { return new int[]{1234, 2}; }

2.x returns ["1,234.50","2.00"] / ["1,234.00","2.00"]. With this PR it returns ["1234.5","2.0"] / ["1234","2"]. Please skip this branch when field.hasTransformation() and add a test for formatted arrays.

[RoMiRoSSaN]

fixed

[RoMiRoSSaN]

@phillip-kruger Thanks for pointing that out. I missed it. I've fixed it and added more tests. Looking forward to your further feedback. I've applied the fixes to both pull requests. In the meantime, I'll also test the fixes in my projects using my local fork.