Different behaviour between local and remote azure app (hotchocolate 12 and 13)

[sipronunciaaigor]

Hi,
I'm quite new to graphql and hotchocolate and many of the concepts behind this approach to with APIs.
I encountered an issue after updating to HotChocolate 12 as, at a certain point, I got the following error Double cannot parse the given literal of type 'StringValueNode'.", when I was trying to send a mutation to my remote host through Postman.
Sending the same mutation to my local environment didn't error.

Same issue when using the custom GUI instead of Postman.

I noticed HotChocolate 13 was in preview and I thought it might have had some changes that affected me. It actually had and now I get that same behaviour for any type which is not a string: almost any type (you choose) cannot parse the given literal of type 'StringValueNode'.",

It happens only against my remote host.
Locally: flawless.

Please note that I'm not doing anything I'd consider "advanced", like stitching or so.
I only extend a bit of the ObjectType<MyType> for some fields with few resolvers. I tried disabling them and using only super-shallow models, without resolvers, but I still get the error (I narrowed down to a model with only strings and DateTime and my DateTime errors out when calling remote).

Given I'm not sure it's an issue from HotChocolate, I'm raising this as a discussion first.
Would anyone have any clue or any similar experience in regard?

[sipronunciaaigor]

After digging deeper in the issue, I was able to narrow down to only a handful of types that allowed me to consistently reproduce the error in isolation and they are all the types that include a date or time, and any non integer type (so any number with decimal positions).
I guess the only difference between running my tests locally or against remote would have been the available culture/localization settings (commas vs. dots for decimals; dd/mm/yyyy vs yyyy/mm/dd vs mm/dd/yyyy etc.)
As an example trying to send a DateTime as 28/06/2022 was successful locally and a failure against remote.
Sending 2022/06/28 resulted as a success on both environments.
I still can't fully explain (and I won't investigate further) why I got the error on doubles and floats with HotChocolate 12, though, as I used only v13 to rerun all my attempts.
My initial tests on HotChocolate12 were simply using 0 as a value for doubles (no decimals) and it used to return that error.