Error Proxying

[yaacovCR]

See #37, where I tried to distill a little bit how execution of a request against a composite schema is sometimes -- but not always -- accomplished by sending request(s) to the original subschemas.

In such a scenario, the original subschema may return an error.

• In order to be most useful, the original subschema should always return any field errors with the path to the field causing the error.
• In order to be spec compliant, the error returned with execution against the composite schema should always return an error with a path to the field in the original request, rather than with the path to the field in the subschema.
  • Beyond simply spec compliance (although that is reason enough!), this is also extremely useful because a composite schema may itself be a source subschema for some other subschema.

It may be helpful to build into GraphQL Errors the ability to specify structured additional info, so that, for example, the original error with the path to the field in the subschema could also be optionally returned to the client. See: graphql/graphql-spec#893

[benjie]

Side note: in addition to why, we do have extensions on errors which we can use for this or any other metadata.

[yaacovCR]

Yes! I referenced why above but any structured approach could work.

Although I am aiming maximally in our composition discussions to try to surface “mainline” spec changes whenever possible that could be useful for composition purposes, it may be that a composition spec also ends up for some use cases not formally extending the mainline spec and rather simply using user-level-like conventions like extensions.

At this stage, I am still just attempting to explore the problem space, with all solutions pretty tentative!

[yaacovCR]

it may also be useful if a graphql response error was also more explicit about how null bubbling occurred.

currently, if a child field raises an error and is non-null, the client can deduce that a parent nullable field was null because of the child error. This is information that could be made plainly available, either by optionally embedding the error in the data array, or by adding additional metadata to the response that includes the “consequences” of an error.

gateways processing responses from subschemas may benefit from directly understanding that a null in a response was caused by an error.

this can be deduced from a properly pathed child error and knowledge of the schema, but could be made plain within the response.

[LunaticMuch]

This is information that could be made plainly available, either by optionally embedding the error in the data array, or by adding additional metadata to the response that includes the “consequences” of an error.

This is interesting. Indeed, I see the need to surface better error in some cases. Clarifying the nullable parent is definitely a case here.

I am less happy with the why above, I can't see more value than the extensions. And you can play well with extensions defining a good standards for error so that the client can get absolute clarity on what's happening.