Appended is the message you get if you make a mistake in a type declaration.
This is quite a likely mistake: it occurs when you copy a type from a query schema into an input schema and forget to change it from type to input.
Ideally the message would include the text of the line that is the problem:
type VariationInput {
or at least the name of the thing that has the wrong type
VariationInput.
I had a look to see if I could quickly make a patch for this, but unfortunately there doesn't appear to be much context obviously available at the place this message is generated :(
/Users/mgregory/NRN/src/agreeonit/apollo_server/node_modules/graphql/jsutils/invariant.js:19
throw new Error(message);
^
Error: Expected Input type.
at invariant (/Users/mgregory/NRN/src/agreeonit/apollo_server/node_modules/graphql/jsutils/invariant.js:19:11)
at produceInputType (/Users/mgregory/NRN/src/agreeonit/apollo_server/node_modules/graphql/utilities/buildASTSchema.js:238:29)
at /Users/mgregory/NRN/src/agreeonit/apollo_server/node_modules/graphql/utilities/buildASTSchema.js:336:18
at /Users/mgregory/NRN/src/agreeonit/apollo_server/node_modules/graphql/jsutils/keyValMap.js:36:31
at Array.reduce (native)
at keyValMap (/Users/mgregory/NRN/src/agreeonit/apollo_server/node_modules/graphql/jsutils/keyValMap.js:35:15)
at makeInputValues (/Users/mgregory/NRN/src/agreeonit/apollo_server/node_modules/graphql/utilities/buildASTSchema.js:333:36)
at fields (/Users/mgregory/NRN/src/agreeonit/apollo_server/node_modules/graphql/utilities/buildASTSchema.js:410:16)
at resolveThunk (/Users/mgregory/NRN/src/agreeonit/apollo_server/node_modules/graphql/type/definition.js:115:40)
at GraphQLInputObjectType._defineFieldMap (/Users/mgregory/NRN/src/agreeonit/apollo_server/node_modules/graphql/type/definition.js:569:20)
Of course the next thing that happens is that you fix the primary declaration and forget to fix the internal fields:
Get Error: Expected Input type.
Change
type VariationInput {
project: Project!
to
input VariationInput {
project: Project!
and the exact same message appears!
(because it needs to be
input VariationInput {
project: ProjectInput!
Thanks for the report. Since this occurs within buildASTSchema, I think the right way to fix this would be to report the file/line/column along with the error.
We do something similar for SyntaxErrors, so hopefully most of this can be recycled by anyone who would like to take this on.
I'd guess most common case in which this happens is when people forget or haven't learned yet that input types need to be different than output types. Error message could explain that & link to:
http://graphql.org/learn/schema/#input-types
and say if there's a way to share fields between an input and output types (since commonly they're same/similar)
I also just ran into this issue. I got a bit curious: Why is it necessary to strictly differentiate between input and output types? I understand that it's better in terms of performance if an input type doesn't contain read only fields which would be simply ignored as part of the mutation. But this comes at the cost of duplicating the types quite a lot if you happen to have a lot of writeable fields.
Is there a workaround for those cases or is duplicating the structure really the best option? Not sure if I'm missing something.
I have wondered the same thing. I still find the duplication quite frustrating.
However, you can't just use exactly the same list for each purpose, because queries (outputs) often have more or different fields in them than inputs, due to computed data and other factors.
I think it would be great to have a declarative syntax for this that lets you specify the types once and define the input and output fields in the same place. I've seen one attempt at this layered on top of graphql schema, but unfortunately it was too cumbersome for my taste.
I ran into this error message and since it is the only thread that came into my search results I will post how I solved it. Maybe it will help other people.
I inadvertently declared a field of a mutation to be of a custom type instead of a scalar type:
# Throws "Expected Input type."
type Mutation {
editProject(project: Project!) {
...
} : Project
}
# Works
type Mutation {
editProject(project: Int!) {
...
} : Project
}
If you do want to pass "types" to mutations, you should consider using Input Types, as suggested by @lorensr
This appears to be resolved in 0.11.7, so we can probably close this.
Not sure if this issue is fully solved, or if I have a different one, but I get errors like
GraphQLError: Expected type Int, found undefined
when undefined was passed to an Int! parameter in a query. The problem is, I can't tell which parameter.
A more useful error message would mention the name of the parameter:
GraphQLError: Expected type Int for
limit, found undefined
@dandv It's a different issue. Can you please open a separate issue and provide full query and more details?
Most helpful comment
I have wondered the same thing. I still find the duplication quite frustrating.
However, you can't just use exactly the same list for each purpose, because queries (outputs) often have more or different fields in them than inputs, due to computed data and other factors.
I think it would be great to have a declarative syntax for this that lets you specify the types once and define the input and output fields in the same place. I've seen one attempt at this layered on top of graphql schema, but unfortunately it was too cumbersome for my taste.