Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
afuyo opened this issue Feb 6, 2021 · 4 comments
Open

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

afuyo opened this issue Feb 6, 2021 · 4 comments
Labels

Comments

@afuyo
Copy link

afuyo commented Feb 6, 2021

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

@afuyo afuyo added the bug label Feb 6, 2021
@npokr
Copy link

npokr commented Nov 7, 2021

I met the same bug with latest version graphql-java-tools. Workaround with method referencing nested input types works for me. I just wrote something like type Query { dummy(input1: Input1, input2: Input2...): Boolean }, added a trivial implementation and the error is gone.
But this bug is quite annoying.

@tinawu0603
Copy link

Also running into this adding the dummy query worked. But very annoying though to have to do this including all input types with nested inputs :/

@Mahesh-mns
Copy link

This is still not working , Anybody have proper steps to resolve it . Please post it ..

@trung-lai-by
Copy link

Anyone mind putting a sample on how to workaround this?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

5 participants