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

Better error message on "wrong type" found in schema #546

Closed
GreenAsJade opened this issue Oct 28, 2016 · 9 comments
Closed

Better error message on "wrong type" found in schema #546

GreenAsJade opened this issue Oct 28, 2016 · 9 comments

Comments

@GreenAsJade
Copy link

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)
@GreenAsJade
Copy link
Author

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!

@leebyron
Copy link
Contributor

leebyron commented Nov 1, 2016

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.

@lorensr
Copy link

lorensr commented Dec 6, 2016

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)

@amannn
Copy link

amannn commented Dec 21, 2016

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.

@GreenAsJade
Copy link
Author

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.

@j-nolan
Copy link

j-nolan commented Apr 11, 2017

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

@sammarks
Copy link

This appears to be resolved in 0.11.7, so we can probably close this.

@dandv
Copy link

dandv commented Oct 18, 2018

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

@IvanGoncharov
Copy link
Member

@dandv It's a different issue. Can you please open a separate issue and provide full query and more details?

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

No branches or pull requests

8 participants