subgraph errors should bubble up to the next nullable parent field

[Geal]

as described in https://www.apollographql.com/blog/graphql/basics/using-nullability-in-graphql/

With this schema:

type Restaurant {
  name: String!
  rating: Int!
  location: Location!
}

type Location {
  address: String!
}

type LatLng {
  lat: Int!
  lng: Int!
}

type Query {
  restaurants(query: String): [Restaurant]
}

if a subgraph returns a response with this content:

{
        name: "All Star Cafe",
        rating: 5,
        location: null
}

location must not be null, so we register an error, and mark the restaurant itself as null:

{
  "data": {
    "restaurants": [ null ]
  },
  "errors": [{
    "message": "Cannot return null for non-nullable field Restaurant.location."
  }]
}

spec: https://spec.graphql.org/June2018/#sec-Errors

If the field which experienced an error was declared as Non-Null, the null result will bubble up to the next nullable field. In that case, the path for the error should include the full path to the result field where the error occurred, even if that field is not present in the response.

[Geal]

this should probably be done as part of the format_response phase (to avoid walking the tree multiple times)

[Geal]

@cecton ^

[cecton]

Looks interesting!

[cecton]

I'll take this one

[cecton]

Cannot be done before #62 (can be done with #62 though...). Unassigning myself for now....

[Geal]

more context on this: currently subgraph errors are not integrated in the response. If we have something obvious like a connection error to the subgraph, it will be present, but if there was an error for a specific entity, we would get from the subgraph a response with an errors array containing some errors and related path, and those are not gathered right now.

We need to gather the subgraph errors, append their path to the current query plan node's path, and erase the error message (we don't want to expose subgraph info there).
We need to wait until the entire response was received to check the errors and find the next nullable parent field because:

• a field provided by a subgraph might be marked as non null, so it could cross the subgraph entity boundaries
• if another field of the same object is provided by a different subgraph, we could end up with a removed entity due to the first error, but see it added again by the second subgraph query (with missing fields)

[Geal]

aggregating the errors is easy enough. Recognizing nullable fields will be a bit more challenging: when traversing the response with errors, for each field we will need to look up in the schema if it is nullable