Skip to content

Expected type to be a GraphQLInputType, but it wasn't! #479

Open
@afuyo

Description

@afuyo

Description

Mutations with nested input types generate errors see below. I've tried the workarounds with dummy methods but it generates stack overflow instead. The thing is that I have two schemas and both contain nested input types, but I run into the problems with only one of them. The one that is slightly complicated and closer to the real life;)

Expected behavior

Actual behavior

Caused by: graphql.kickstart.tools.SchemaError: Expected type 'InsuranceAgreementCreateOneWithoutInsuranceAgreement_IncludedAgreementInput' to be a GraphQLInputType, but it wasn't! Was a type only permitted for object types incorrectly used as an input type, or vice-versa?
at graphql.kickstart.tools.SchemaParser.determineInputType(SchemaParser.kt:419) ~[graphql-java-tools-6.2.0.jar:na]
at graphql.kickstart.tools.SchemaParser.determineInputType(SchemaParser.kt:402) ~[graphql-java-tools-6.2.0.jar:na]
at graphql.kickstart.tools.SchemaParser.createInputObject(SchemaParser.kt:176) ~[graphql-java-tools-6.2.0.jar:na]
at graphql.kickstart.tools.SchemaParser.determineInputType(SchemaParser.kt:428) ~[graphql-java-tools-6.2.0.jar:na]
at graphql.kickstart.tools.SchemaParser.determineInputType(SchemaParser.kt:402) ~[graphql-java-tools-6.2.0.jar:na]
at graphql.kickstart.tools.SchemaParser.createInputObject(SchemaParser.kt:176) ~[graphql-java-tools-6.2.0.jar:na]
at graphql.kickstart.tools.SchemaParser.determineInputType(SchemaParser.kt:428) ~[graphql-java-tools-6.2.0.jar:na]
at graphql.kickstart.tools.SchemaParser.determineInputType(SchemaParser.kt:402) ~[graphql-java-tools-6.2.0.jar:na]
at graphql.kickstart.tools.SchemaParser.createInputObject(SchemaParser.kt:176) ~[graphql-java-tools-6.2.0.jar:na]
at graphql.kickstart.tools.SchemaParser.parseSchemaObjects(SchemaParser.kt:79) ~[graphql-java-tools-6.2.0.jar:na]
at graphql.kickstart.tools.SchemaParser.makeExecutableSchema(SchemaParser.kt:112) ~[graphql-java-tools-6.2.0.jar:na]
at

Steps to reproduce the bug

  1. failsagreement schema with corresponding FailsAgreement.java resolvers is the one generating errors.
  2. worksperson schema with corresponding WorksPerson.java resolvers works fine.
  3. Both schemas contain same kind of nested input types and programmatically generated. Both schemas run fine on Prisma backend.

Source code:
https://github.com/afuyo/grapql-mutations-on-Kafka

Would be grateful for any input.

/Artur

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions