Apollo-ios: Granularity in error handling

[MrAlek]

Currently, errors are delivered at root-level together with the data in GraphQLResult, although errors from apollo-server typically provides a path to the field which failed to load due to the error.

From an error handling perspective, it would be great to easily propagate those errors to their corresponding fields without manually parsing a key path.

Example:

{
  "data": {
    "items": [
        {
            "id": "abc123",
            "someField": "A nice item"
        },
        {
            "id": "cba987",
            "someField": null
        }
    ] 
  },
  "errors": [
    {
        "id": "f2347426-10b0-4c94-9bd2-9eedafa725f7",
        "code": "could-not-fetch-field",
        "path": "items.1.someField"
      }
  ]
}

You fetch a paginated resource with a few fields per item to display in a table view. In this case, it is desirable to separate errors fetching the list altogether from errors relating to a field on an individual item in the list. That way, you could replace a single data cell with another one representing the error on that specific index.

If you would try to do this in the current setup, you would have to parse the path with regex or such on a per-operation basis which particularly adds overhead when reusing fragments in multiple queries.

A possible solution would be to let each data struct have an errors (+ aggregatedErrors) array which holds errors related to fields on that object. What are your thoughts?

[designatednerd]

@MrAlek Obviously this question predates my joining the project, but I'm curious: Is the JSON you're showing above what you're actually getting back, or what you propose to get back? Are you still seeing issues around this?

[MrAlek]

@designatednerd The JSON represents what's usually returned by a GraphQL server, all errors are received at root level. In the example above, data.items[1].someField is null because it couldn't be fetched, server-side.

What I was proposing was to, in the Swift structs generated by Apollo codegen, propagate errors down the chain to the leaf responsible for the error (items.1.someField), so you could deal with partial failure, like this, easier.

[designatednerd]

OK thank you for the clarification - this one is probably going to be a bit lower on the priority list but it does seem quite useful, I'll tag it as an enhancement.