Nested Input Types Are Not Working (again)

Using version 4.1.2 and graphql-spring-boot-starter 3.9.2

schema file:

input DiscountTypeFilter{
code_text_is: String
id_is: Long
}

input RequestFilter{
event_date_greater: Long
discount_type_filter: DiscountTypeFilter
}

input MaterialFilter{
title_contains: String
discount_type_filter: DiscountTypeFilter
}

I get a spring boot error that is root caused here:
Caused by: com.coxautodev.graphql.tools.SchemaError: Expected type 'DiscountTypeFilter' 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 com.coxautodev.graphql.tools.SchemaParser.determineType(SchemaParser.kt:248) ~[graphql-java-tools-4.1.2.jar:?]
at com.coxautodev.graphql.tools.SchemaParser.determineInputType(SchemaParser.kt:236) ~[graphql-java-tools-4.1.2.jar:?]
at com.coxautodev.graphql.tools.SchemaParser.access$determineInputType(SchemaParser.kt:48) ~[graphql-java-tools-4.1.2.jar:?]

Throwing a debugger on it the allowable types array at the time it's throwing the error are MaterialFilter and MaterialDTO which is a type object I have that instantiates fine. I'm not sure why it doesn't recognize RequestFilter or DiscountTypeFilter as additionally allowable types?

Any help is appreciated

Does it log a warning that those types aren't used and can be deleted? It seems like the scanner isn't finding usages of those types so they aren't making it into the parser.

Ah, yes, it is logging that and I missed it with all the other stuff spring boot was spitting in my console. What do I do about that to fix it? (Apologies if I missed that in the documentation) I saw the unused resolvers option but that it's not for production so I'm a little confused as to whether I should turn it on as I would need this to run in production as well, eventually. (actually that doesn't sound like what i need here anyways?)

Actually, the thought strikes me it might be useful to have a way to not delete things that aren't "used" as an option. Something tells me we'll hit this more than a couple times if everything doesn't do full recursion into nested types of all kinds due to how our schema works.

It seems like a bug in the scanner that isn't finding those types properly. Do you have a full schema you can send me? I have a few tests in the library and I'm not sure how your schema differs from them.

@apottere

@apottere

Sure, I've pared out the company specific items in this one, but it shows the problem fully.

type DiscountType{
id: Long!
name: String!
}

type Material{
id: Long!
request: Request!
ISBN: String
title: String!
format: MaterialFormat!
quantity: Int!
lastModified: Long!
lastModifiedBy: String!
}

type Request{
id: Long!
eventDate: Long!
discountType: DiscountType!
}

input DiscountTypeFilter{
name_is: String
id_is: Long
}

input RequestFilter{
AND: [RequestFilter!]
OR: [RequestFilter!]
event_date_greater: Long
discount_type_filter: DiscountTypeFilter

}

input MaterialFilter{
title_contains: String
request_filter: RequestFilter
}

enum MaterialFormat{
HARDCOPY
EBOOK
CERTIFICATE
OTHER
}

type Query {
materials(filter: MaterialFilter): [Material]!
}

schema {
query: Query
}

A workaround to force them to be picked up is changing the query to this:

type Query {
materials(filter: MaterialFilter): [Material]!
requests(filter: RequestFilter): [Request]!
discountTypes(filter: DiscountTypeFilter): [DiscountType]!
}

Basically if they're in the root query object directly they get picked up, but if they're only nested inside another filter, they're never picked up.

@SignalDancer
Hi, could you retest with latest SNAPSHOT version? I think that this commit 327a82b might fix also this issue.

Hello,

I just tried having nested input types in version 4.3.0 and it does not work.

Hello,
I have the same problem. SchemaParser does not find nested input types.

I'm not sure, if it is a related issue:
I have an input type with an enum value, which produces the same failure:

input Request {
    order: Direction
}

enum Direction {
    ASC
    DESC
}

The scanner also says "Schema type was defined but can never be accessed, and can be safely deleted: Direction" although the request is defined directly in the root/query-resolver.

I was running into this on 4.3.0, specifically using nested input objects for mutations. The workaround from @SignalDancer was enough to build my schema, but during query execution I was getting UnrecognizedPropertyExceptions from jackson. I added @JsonProperty annotations to the fields on my data classes for those mutations, and it is working correctly now. Hope that helps others get it running. I don't have time to put in a fix, but I can help test if someone gets around to it.

@mikeurbach

@mikeurbach I have the same issue with 4.3.0.

@warmwind

@warmwind did you try this workaround? #77 (comment). that, and adding @JsonProperty annotations on the fields of the nested input class worked for me.

I had a very similar problem and managed to resolve it by making sure my resolver function had the corresponding parameter.
E.g. the following schema:

type Query {
    findAuthors(filter: [Operand]): [Author]
}

input Operand {
    operand: String!
    filters: [AllPurposeFilter]!
}

input AllPurposeFilter {
    firstProperty: String!
    operator: String!
    secondProperty: String!
}

And the Java classes Operand and AllPurposeFilter containing the fields annotated with @JsonProperty.
E.g.

@JsonProperty("operand")
public String getOperand(){
    return this.operand;
}

in the Operand class.

The resolver method looks like that:

public List<Author> findAuthors(List<Operand> operands) {
   // ...
}

@mikeurbach

@mikeurbach Thanks. We finally do not use this lib and only use graphql-java

I am having this issue, I can perhaps work around it, but any traction of a fix?

Issue is fixed. See unit test NestedInputTypesSpec for working example.

looks like still not working with nested enums and custom scalar types
please add this cases to NestedInputTypesSpec
i am getting on 5.5.1

com.coxautodev.graphql.tools.SchemaError: Expected type 'MyEnumOrScalarType' 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 com.coxautodev.graphql.tools.SchemaParser.determineType(SchemaParser.kt:331)

looks like still not working with nested enums and custom scalar types

I'm seeing the same issue.

This is still an issue as of 5.10.0. Exposing the nested input type in a separate root query/mutation solves the issue. Though this is most likely not the most ideal workaround.

@davis91

This is still an issue as of 5.10.0. Exposing the nested input type in a separate root query/mutation solves the issue. Though this is most likely not the most ideal workaround.

@davis91 ...could you explain "Exposing the nested input type in a separate root query/mutation" and possibly give an example? I've run into this issue and am trying to find a solution/workaround.

@davis91

This is still an issue as of 5.10.0. Exposing the nested input type in a separate root query/mutation solves the issue. Though this is most likely not the most ideal workaround.

@davis91 ...could you explain "Exposing the nested input type in a separate root query/mutation" and possibly give an example? I've run into this issue and am trying to find a solution/workaround.

He means that the only way for the nested input type to get picked is to create a Query/Mutation that explicitly refers to it, which isn't a proper solution

This is still a thing.
Anyone found a proper solution, that doesn't involve implementing a dummy query/mutation?

For me, it worked with a single mutation referring to an input type. No problem.
But when I added a second mutation with a different input type it broke.
Implementing the dummy fixed it.

Edit:
This behaviour only happens to the saveProject mutation, which is, as far as I can see, pretty similar to the saveProfile mutation.
Both use a 'complex' nested input type, which in turn only contain scalars.

type Query {
    profile(username: String!): Profile!
    profiles(count: Int = 10, page: Int = 0): [Profile!]!
    project(id: Int!): Project!
    projects(count: Int = 10, page: Int = 0): [Project!]!
}

type Mutation {
    #Only implementing this works
    saveProfile(input: ProfileInput!): Profile!
    #When I implement this, it breaks
    saveProject(input: ProjectInput!): Project!
}

#### Types ####
type Profile {
    id: ID!
    name: String!
    img: String!
    email: String!
    username: String!
    skills: [Skill!]
    projects: [Project!]
}

type Project {
    id: Int!
    name: String!
    description: String
    technologies: [Technology!]
    profiles: [Profile!]
}

type Skill {
    id: Int!
    name: String!
    level: Int!
}

type Technology {
    id: Int!
    name: String!
}


#### Inputs ####
input SkillInput {
    id: Int
    name: String!
    level: Int!
}

input TechnologyInput {
    id: Int
    name: String!
}

input ProfileInput {
    id: ID!
    firstName: String!
    lastName: String!
    email: String!
    username: String!
    img: String!
    skills: [SkillInput!]
    projects: [Int!]
}

input ProjectInput {
    id: Int!
    name: String
    description: String
    technologies: [TechnologyInput!]
    profiles: [ID!]
}

So, I think I have a lead here.

TL;dr check if all field names in your POJO match those in your schema definition

After endlessly reviewing my code I found that I made a typo in the corresponding java class.
The relevant SDL code would be:

input ProjectInput {
    id: Int
    name: String
    description: String
    technologies: [TechnologyInput!]
    profiles: [ID!]
}

input TechnologyInput {
    id: Int
    name: String!
}

which is corresponding to my model class for ProjectInput

@Data
@AllArgsConstructor
@NoArgsConstructor
public class ProjectInput {
    private int id;
    private String name;
    private String description;
    // The typo was in this line. I miss typed "technolgies"
    private List<TechnologyInput> technologies;
    private List<String> profiles;
}

As you can see, with the typo the name of the field it doesn't match the property in my SDL definition anymore.
After fixing the typo my code compiles without error.

My hypothesis would be, that the variables need to be the same name as stated in the schema definition.
Is this intended behavior? Or did I simply miss something?

I hope this might help some people.

That sounds like a reasonable expectation. I have opened this to track the problem: #422

@IKS-Ploetzwich

@IKS-Ploetzwich This was the exact issue for me as well!!

looks like still not working with nested enums and custom scalar types

I'm seeing the same issue.

looks like still not working with nested enums and custom scalar types

I'm seeing the same issue.

Can you give us more information how to reproduce this? Ideally a PR with a failing test case.

@IKS-Ploetzwich

@IKS-Ploetzwich you are my hero ! thanks a lot I had a typo as well.

The error message in this case is very misleading. Could it be improved to indicate that the field specified in the schema cannot be found in the corresponding java class instead of saying "Expected type 'MyFilter' to be a GraphQLInputType, but it wasn't!" ?

Navigation Menu

Repository navigation

Nested Input Types Are Not Working (again) #77

3 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Nested Input Types Are Not Working (again) #77

Description

Activity

apottere commented on Oct 9, 2017

hdaws commented on Oct 9, 2017

apottere commented on Oct 11, 2017

hdaws commented on Oct 12, 2017

hdaws commented on Oct 12, 2017

jakubkluz commented on Nov 23, 2017

KaRkY commented on Feb 9, 2018

PMisudik commented on Feb 12, 2018

geesen commented on Feb 12, 2018

mikeurbach commented on Mar 14, 2018

warmwind commented on Apr 12, 2018

mikeurbach commented on Apr 16, 2018

PatrickSchuster commented on May 4, 2018

warmwind commented on May 18, 2018

CH-EricLundberg commented on Jul 30, 2018

3 remaining items

oliemansm commented on Sep 23, 2018

zhuravskiy commented on Mar 14, 2019

adrian-baker commented on Apr 10, 2019

mrFatDZ commented on Oct 4, 2019

kemsar commented on Oct 23, 2019

joarobles commented on Jan 20, 2020

IKS-Ploetzwich commented on Jul 22, 2020

IKS-Ploetzwich commented on Jul 23, 2020

vojtapol commented on Jul 23, 2020

ybhatnagar commented on Sep 30, 2020

sbmaggarwal commented on May 16, 2021

vojtapol commented on May 17, 2021

mryan43 commented on Sep 30, 2021

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions