-
Notifications
You must be signed in to change notification settings - Fork 2k
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
Comments
Of course the next thing that happens is that you fix the primary declaration and forget to fix the internal fields: Get Change
to
and the exact same message appears! (because it needs to be
|
Thanks for the report. Since this occurs within 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
when A more useful error message would mention the name of the parameter:
|
@dandv It's a different issue. Can you please open a separate issue and provide full query and more details? |
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 fromtype
toinput
.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 :(
The text was updated successfully, but these errors were encountered: