Fix: Accept all valid Float value inputs on coerce_variable_value

[rb090]

This PR fixes the behaviour of Float input values in the apollo-compiler crate in apollo_compiler::request::coerce_variable_values to align with the GraphQL specification.

The GraphQL specifications defines the input coercion like this:

When expected as an input type, both integer and float input values are accepted. Integer input values are coerced to Float by adding an empty fractional part, for example 1.0 for the integer input value 1.

The issue this PR solves is, that coerce_variable_values incorrectly rejects JSON numbers without fractional parts (e.g. 42) when the corresponding input variable type was Float.

The changes include accepting any JSON number (int or float) that can be converted to an f64 for Float inputs as well as a small unit test test_graphql_float_variable_coercion showing the behaviour.

Big thanks to my colleague David, who identified where the changes needed to be applied and also reviewed the code updates. Much appreciated! 🙌

Once PR#1001 fix(smith): apply new clippy rules from Rust 1.90 is merged, the CI on this PR will fully succeed. It fails yet on cargo clippy --all-targets --all-features -- -D warnings because of the code in crates/apollo-smith/src/schema.rs fixed in PR#1001. → ✅

[apollo-cla]

@rb090: Thank you for submitting a pull request! Before we can merge it, you'll need to sign the Apollo Contributor License Agreement here: https://contribute.apollographql.com/

[lrlna]

Thank you so much for your contribution! There are few small things to fix, which I've noted in the review comments. Once those are in, I can merge this in.

[lrlna]

This test won't run as is. It needs to be added to apollo-compiler/tests/validation/main.rs. Once added, you will notice rust compiler won't compile this file, and you will need to declare Schema, ExecutableDocument and coerce_variable_values.

[rb090]

I’ve moved input_coercion.rs to apollo-compiler/tests/validation directory and added its declaration to apollo-compiler/tests/validation/mod.rs with c5f4bac. I believe this is what you were referring to?

[lrlna]

Ah sorry, my bad, I typed out the path wrong. Where you had it was good - input coercion is not a validation rule. It needed to be added to apolo-compiler/tests/main.rs as mod input_coercion (and I wrote apolo-compiler/tests/validation/main.rs, leading to confusion).

[rb090]

Thank you for clarification @lrlna 🙌. You are right on this. I moved it to apollo-compiler/tests/ and correctly adjusted apollo-compiler/tests/main.rs in a4c357e like you wrote.

[lrlna]

Could I ask you to add another test to this file that shows how coercion would fail?

Since we have changed the coercion code to now be value.as_f64().is_some_and(f64::is_finite), there is a chance for a None to be returned from as_f64. You might have to have kilometers_value be defined as a string, otherwise the compiler won't let this compile. So potentially two variations of the test like this:

// Infinity; should fail coercion
let kilometers_value = "1e1000";

and another one:

// i128 MAX; should also fail coercion, since it's > i64 MAX
let kilometers_value = "170141183460469231731687303715884105727";

[rb090]

Great catch, thank you! It seems that the coercion changes I made in resolvers/input_coercion.rs didn’t fully cover the case involving values beyond i128::MAX. The extended unit tests helped me spotting this edge case.

I’ve fixed the issue in 23d67b8 and also refactored tests/input_coercion.rs to reduce code duplication and improve readability.