What's roughly the schedule for getting 5.0 out at...

# graphql-kotlin

[Jilles van Gurp]

What's roughly the schedule for getting 5.0 out at this point? We are using 4.x currently but it kind of makes upgrading spring, kotling, co-routines, etc. a bit tedious due to the outdated versions of those that 4.x still uses. 5.x seems to fix that so we'd like to either switch to that or maybe it would be possible to get a maintenance release for 4.x? We got it working with kotlin 1.5.10 and co-routines 1.5.0. But going beyond that, it seems stuff starts breaking. I tried this last week with the latest spring boot and co-routines 1.5.1 and suddenly we got a lot of schema errors. It compiles and builds fine but our tests fail due to this.

[Shane Myrick]

@Dariusz Kuc were just discussing this yesterday. At this point we are not going to wait for graphql-java 17 or spring-graphql as it appears there is a need now for some of the features in 5.0 already. So once we get the last PRs merged. We should be good to go.

As for the current alpha version, please try integrating of you can atleast in a dev branch. We don’t expect any more major changes so a RC release should be coming soon but any issue that can be found before that would help,

[Jilles van Gurp]

I'm getting a could not find com.expediagroup:graphql-kotlin-spring-server:5.0.0-alpha.2

With alpha0 I get similar errors as earlier. I assume this has to do with language changes in 1.5. I can try again if you fix the release jars for alpha2 or a new alpha3.

org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'schema' defined in class path resource [com/expediagroup/graphql/server/spring/NonFederatedSchemaAutoConfiguration.class]: Bean instantiation via factory method failed; nested exception is org.springframework.beans.BeanInstantiationException: Failed to instantiate [graphql.schema.GraphQLSchema]: Factory method 'schema' threw exception; nested exception is com.expediagroup.graphql.generator.exceptions.InvalidInputFieldTypeException: Argument cannot be an interface or a union, parameter #2 output of fun com.tryformation.graphqlapi.indooratlas.IAPoint.`write$Self`(com.tryformation.graphqlapi.indooratlas.IAPoint, kotlinx.serialization.encoding.CompositeEncoder, kotlinx.serialization.descriptors.SerialDescriptor): kotlin.Unit

[Dariusz Kuc]

yeah both alpha.1 and alpha.2 failed to release due to dokka dependency, I just kicked off alpha.3

[Dariusz Kuc]

5.0.0-alpha.3 was just released

[Dariusz Kuc]

unsure if that will solve your issue as based on your error it sounds like an issue with kotlinx.serialization and spring - it looks like it complains about the CompositeEncoder (and will be complaining about SerialDescriptor ) argument to the write$Self function -> should that function be exposed in the graph at all?

[Jilles van Gurp]

alpha 3 still has the issue indeed. It looks like something is weird with serialization. This particular class seems like it should just work. I suspect the error is simply misleading/unhelpful as we have more complex stuff in our schema including some sealed classes.

@Serializable
data class IAPoint(val lat: Double, val lon: Double)

[Dariusz Kuc]

since kotlinx.serialization uses compiler plugin to generate the classes my guess is graphql-kotlin picks those autogenerated methods (through reflection) while building a schema, unsure if there is an easy way to skip those.

[Dariusz Kuc]

since we are targeting jackson for servers I am unsure if we will be fixing it (PRs are always welcome)

[Jilles van Gurp]

Thanks, I suspected something like that. We were using kotlinx serialization before without issues. It's only with this release that it became problem. We are relying on kotlinx serialization for our multiplatform API client and of course would like to use the same model classes for our API and client.

In general, multiplatform and kotlinx serialization might eventually become relevant for servers as well. I believe Spring already has some support for kotlinx serialization. So, not ideal to not be able to support that.

[Jilles van Gurp]

@Dariusz Kuc I found a workaround:

Added this to our SchemaGeneratorHooks

override fun isValidFunction(kClass: KClass<*>, function: KFunction<*>): Boolean {
        return if(function.name == "write\$Self")
            // generated by kotlinx serialization
            false
        else
            super.isValidFunction(kClass, function)
    }e

[Jilles van Gurp]

still not sure what changed in kotlin 1.21 that causes the default logic to change for this.
I created an issue for this: https://github.com/ExpediaGroup/graphql-kotlin/issues/1246