Inconsistent behavior within InputParser, when parse nullable scalar value in HC 13 in compare with 12

[dkogithub]

Is there an existing issue for this?

• [X] I have searched the existing issues

Product

Hot Chocolate

Describe the bug

If there is a input type which has 2 fields like

{
documentId: String
revision: Int
}

If the query with this input type argument run like:

query myquery {
                       tests{
                         test(documentVersion: {documentId: "myid", revision: null}) {
                           revision
                         }
                       }
                     }

InputParser parse "revision" as null - which is expected, but in case the query run without "revision" parameter InputParser parse it as default Int32 value - 0.

HC 12 code retuned null in both cases.

It happens here, which I think is incorrect behavior: https://github.com/ChilliCream/graphql-platform/blob/96b9a9c4198d7f13a15b10f617f536c1ca15d3c6/src/HotChocolate/Core/src/Types/Types/InputParser.cs#L662

the code comment says: // if the type is nullable but the runtime type is a non-nullable value // we will create a default instance and assign that instead. which makes no sense to me, if the field nullable why it's need to forcedly set to default not nullable value?

Steps to reproduce

1. Build/Run attached repro.zip project
2. Open "serverPath/graphql/ui" Banana Cake url
3. Run query:

query  myquery{
    testData (documentVersion: {documentId: "mydocId", revision: null}){
      id
    }
}

4. Note that revision field is null within resolver method, which is expected.
5. Run another query, without revision parameter specifying:

query  myquery{
    testData (documentVersion: {documentId: "mydocId"}){
      id
    }
} 

6. Note that this time revision fields is equals 0, which is not expected for nullable field.

Relevant log output

No response

Additional Context?

No response

Version

13.3.3

[michaelstaib]

13 is correct as the GraphQL spec in the case that you do not provide a value demands that the default value shall be provided.

https://spec.graphql.org/draft/#CoerceArgumentValues()

This was probably a bug in version 12 that we fixed with 13.

[michaelstaib]

I might have misread here. So in your case you do not have a default value?

[michaelstaib]

I just see that you are not using typed objects ... that is causing this issue. I will write a test for this. I think the runtime type in this case is incorrectly inferred.

In any case I would not use the arguments in this way as it will result in a much larger memory footprint. Just an advice. In any case, I will have a look at it.

[jeffrimko]

Also being affected by this issue in HC 13.9.0. In case anyone else runs into this, like the OP mentioned, the workaround for now is to explicitly set any scalar field to null if it is a value type (i.e. int, bool, enum, etc).