Codegen GraphQL Float should be Kotlin Double

[bwilliams]

Version

3.8.4

Summary

The gradle Kotlin codegen plugin is mapping GraphQL Float to kotlin.Float when it should be using kotlin.Double

Steps to reproduce the behavior

Follow codegen instructions.

Execute query in code on an API with GraphQL Float values that don't fit in a kotlin Float

Error "Can't serialize value ...: Expected type 'Float' but was 'Double'.

Logs

(Your logs here)

[martinbonnin]

This is unexpected. The GraphQL Float should be mapped to kotlin.Double by default. Can you elaborate a bit more on your setup? What is your schema/query? What exception are you getting?

[bwilliams]

I'm using gradle to build kotlin client code from a graphql schema/query and the gradle codegen plugin.

It looks like here's the problem.

[bwilliams]

Sorry there was also a problem on the producing server getting kotlin's NaN and Infinity triggered that was fixed. I can try to trigger an exception tomorrow.

[martinbonnin]

It looks like here's the problem.

Good catch, this should be kotlin.Double. It's used when writing the schema type:

public class GraphQLFloat {
  public companion object {
    // Should be kotlin.Double here instead
    public val type: CustomScalarType = CustomScalarType("Float", "kotlin.Float")
  }
}

It is also very unlikely to be your problem.

This is almost never used as the builtin scalars are optimized at build-time and do not use the custom scalar path. The only way you'd have to use it would be to reference GraphQLFloat.type.className which is not very usual.

Let us know if you can reproduce. If you can share the full stacktrace so that we get a better idea where this error is coming from. It might very well come from the server as you found out.

[martinbonnin]

Hi @bwilliams were you able to reproduce? Anything we can help with here?

[martinbonnin]

Hi @bwilliams, I'm going to assume this is working.

We made the change in 4..0.0-rc.1 to generate Double instead of Float and we'll backport it to 3.x but it's very unlikely to be the problem here. Let us know if you need anything else.

[github-actions]

Do you have any feedback for the maintainers? Please tell us by taking a one-minute survey. Your responses will help us understand Apollo Kotlin usage and allow us to serve you better.