Skip to content
This repository has been archived by the owner on Jul 25, 2024. It is now read-only.

Mutations: When non-null fields are not specified, the query should report errors #56

Open
aweiker opened this issue Feb 12, 2016 · 10 comments

Comments

@aweiker
Copy link
Member

aweiker commented Feb 12, 2016

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.

@joshprice
Copy link
Member

I think there is a todo in the executor that mentions this if you want to investigate

@aweiker
Copy link
Member Author

aweiker commented Feb 13, 2016

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.

@AdamBrodzinski
Copy link
Member

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."
    }
  ]
}      

@erikstenlund
Copy link

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.

@aweiker
Copy link
Member Author

aweiker commented Feb 29, 2016

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.

@bringking
Copy link

@aweiker Is this still in progress? Do you guys need any help?

@aweiker
Copy link
Member Author

aweiker commented Nov 30, 2016

I believe this is done as a part of #82.

@bringking
Copy link

@aweiker okay cool, is there an example or a way to add errors to the error list that gets returned to the client?

@aweiker
Copy link
Member Author

aweiker commented Nov 30, 2016

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.

@bringking
Copy link

@aweiker raising an error worked great. Thank you for the clarification!

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

No branches or pull requests

5 participants