graphql-ruby: Incorrect behavior on error handling of a mutation with multiple root fields

Hello,

once again, thanks for this amazing work. I think I’d run into a bug regarding error handling when executing multiple mutation fields on the same mutation. Please consider:

mutation myDemoMutation {
  check_in(input: { id:"some-id"}) { ... }
  second_mutation: check_in(input: { id:"another-id" }) { ...   }
}

Now suppose the first field raises a not authorized GraphQL::ExecutionError exception. The api output is something along these lines:

{
  "data": null,
  "errors": [
    {
      "message": "You are not authorized to perform this action",
      "locations": [
        {
          "line": 8,
          "column": 3
        }
      ],
      "path": [
        "check_in"
      ]
    }
  ]
}

As you can see data is null, and hence no output is present for second_mutation. However, after inspecting the system state, I can verify that the mutation has been executed and the side-effects caused by it still persist.

In other words, the check_in operation of the second mutation executes successfully although the requester is unable to retrieve a response for it.

I believe the expected behavior should include the response for second_mutation under data, null for the first mutation, while also exposing the error for the first mutation under errors.

{
  "data": {
    check_in: null,
    second_mutation: { 
      # fields requested on the mutation field selection
    }
  },
  "errors": [
    {
      "message": "You are not authorized to perform this action",
      "locations": [
        {
          "line": 8,
          "column": 3
        }
      ],
      "path": [
        "check_in"
      ]
    }
  ]
}

Reference: graphql specs (https://facebook.github.io/graphql/#sec-Errors-and-Non-Nullability),

If an error is thrown while resolving a field, it should be treated as though the field returned null, and an error must be added to the “errors” list in the response. [ … ] If all fields from the root of the request to the source of the error return Non-Null types, then the “data” entry in the response should be null.

Could you please confirm if my assumptions and interpretation of the specs are correct? If affirmative any chance we could have this fixed in upcoming releases?