Multiple queries/mutations in single request tricky due to errors decoupling

[chladog]

mutation createTest {
  test1:createUser(data: { email: "[email protected]", password: "test" }) {
    email
  }
  
  test2:createUser(data: { email: "[email protected]", password: "" }) {
    email
  }
  
    test3:createUser(data: { email: "[email protected]", password: "test" }) {
    email
  }
}

This query will result in response that has couple of problems:

{
  "errors": [
    {
      "message": "The following field is invalid: email",
      "data": [
        {
          "message": "A user with the given username is already registered",
          "field": "email"
        }
      ]
    },
    {
      "message": "The following field is invalid: email",
      "data": [
        {
          "message": "A user with the given username is already registered",
          "field": "email"
        }
      ]
    }
  ],
  "data": {
    "test1": null,
    "test2": null,
    "test3": {
      "email": "[email protected]"
    }
  }
}

1.) we can see one of the subtask was successful, but there are 2 error which we are unable to connect with each subtask
2.) BUG: the error of the 2nd (and any other) invalid subtask is overwritten by the error of the 1st invalid subtask - as the error of 2nd invalid subtask should actually be "No password was given" as [email protected] is actually NOT existing, running the subtask separately in own request will return correct message.

From my experience a great solution to the first problem is to move error handling to the query objects as union types. Though it's a change of schema and would need some refactoring of existing projects, but maybe would be worth it as it brings so much flexibility.
The queries and mutations would change to the following sample:

mutation createTest {
  test1:createUser(data: { email: "[email protected]", password: "test" }) {
    ... on User {
      __typename
      email
    }
    ... on ErrorAlreadyExists {
     __typename
     message
    }
    ... on ErrorInvalidInput {
     __typename
     message
     data { ... }
    }
  }

Other solution might be to introduce somekind of "path" to the error object to be able to pair it with the subtask.

The queries here are just to showcase the problems as it's probably not very useful to create multiple users at same time. But there are many useful cases of merging requests, for example bulk updates from list-views.

[DanRibbens]

Wow @chladog, thank you for the level of detail here and in #451.

I can't see us commiting to the union error objects as you described, though that is very interesting. It would be a big pivot from our current GraphQL API.

I'll work up a fix for the bug and we can also add the path and nodes of the error too. After that I can look at #451 and see how we can help you along there.

How does that sound to you?

[DanRibbens]

I have a PR for this one #457

We'll update again when it is released.

[DanRibbens]

When I was working on adding documentation and more testing, this became a bit more complicated.
It is hard to write afterError hook functions that work for both the GraphQL and REST arguments isn't the same with how I had implemented it. I have a solution but I haven't had time to rework this.

[chladog]

Personally I don't mind if I need to write two different hooks, one for GQL and one for REST interface, or just one for the interface I'm using. I was even thinking about a use-case where it would be desirable to have different hook per interface however I didn't think of any :-D so I understand you want to merge them, no rush.

[DanRibbens]

We just released 0.15.0 which has improved the graphql error responses with path and and includes the bug fix so you can see all the errors when there is more than one.
For example a query with:

  test1:createGeolocation (data: {location: [13], localizedPoint: [9], group: { point: [20,20]}}) {
    id
    location
    localizedPoint
      group {
        point
      }
    }
    updateCustomID(id: 24, data: {name: ""}){
      id,
      name
    }

Will now return:

  "errors": [
    {
      "message": "The following fields are invalid: location, localizedPoint",
      "locations": [
        {
          "line": 31,
          "column": 3
        }
      ],
      "path": [
        "test1"
      ],
      "extensions": {
        "name": "ValidationError",
        "data": [
          {
            "message": "This field requires two numbers",
            "field": "location"
          },
          {
            "message": "This field requires two numbers",
            "field": "localizedPoint"
          }
        ]
      }
    },
    {
      "message": "The following field is invalid: name",
      "locations": [
        {
          "line": 39,
          "column": 3
        }
      ],
      "path": [
        "updateCustomID"
      ],
      "extensions": {
        "name": "ValidationError",
        "data": [
          {
            "message": "This field is required.",
            "field": "name"
          }
        ]
      }
    }
  ],
  "data": {
    "test1": null,
    "updateCustomID": null
  }
}

I'll followup again when we wrap up the changes to afterError hook.