graphql
graphql copied to clipboard
Mutations: When non-null fields are not specified, the query should report errors
Currently if a non-null field is no specified in the mutation, the mutation will still execute even though it should return an error.
http://facebook.github.io/graphql/#sec-Non-Null
GraphiQL will indicate that the query is bad, but it will still submit it and the query will get executed.
I think there is a todo in the executor that mentions this if you want to investigate
I was planning on digging in this weekend or next week.
Sent from my iPad
On Feb 12, 2016, at 4:47 PM, Josh Price [email protected] wrote:
I think there is a todo in the executor that mentions this if you want to investigate
— Reply to this email directly or view it on GitHub.
For more info here is what the Node implementation returns when not providing an id param and also when passing in unknown args:
{
"errors": [
{
"message": "Field \"post\" argument \"id\" of type \"String!\" is required but not provided."
}
]
}
{
"errors": [
{
"message": "Unknown argument \"foo\" on field \"post\" of type \"BlogQueries\"."
},
{
"message": "Field \"post\" argument \"id\" of type \"String!\" is required but not provided."
}
]
}
Is somebody currently working on this? Otherwise I started working on adding some error and null checking and could probably get it done this week.
This is being handled as a part of validation.
-Aaron
On Feb 28, 2016, at 5:06 PM, Erik Stenlund [email protected] wrote:
Is somebody currently working on this? Otherwise I started working on adding some error and null checking and could probably get it done this week.
— Reply to this email directly or view it on GitHub.
@aweiker Is this still in progress? Do you guys need any help?
I believe this is done as a part of #82.
@aweiker okay cool, is there an example or a way to add errors to the error list that gets returned to the client?
With the latest version you actually need to raise an error in order for it to get added to the error result. Prior to this refactoring you could return an error tuple.
@aweiker raising an error worked great. Thank you for the clarification!