You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
According to the spec, there is a distinction between "request errors" and "field errors" (and it would most likely make sense to have that distinction in our code base as well).
Field errors are raised during execution from a particular field. This may occur due to an internal error during value resolution or failure to coerce the resulting value.
Field errors must result in a partial response, i.e. a response withdata entry and all (unique) raised field errors in the errors entry. If a field error occurs on a nullable field, the value of that field will be coerced to null. Otherwise, the error propagates to the parent field where it will be handled similarly (if the parent is nullable, it will be coerced to null, otherwise the error propagates further).
This adds first support for schema stitching without aiming for full
feature compatibility. And while I have a pretty extensive internal
use case, schema stitching is still to be considered experimental and
subject to change as needed.
Schema stitching is a way to combine multiple GraphQL schemas under a
single endpoint, so that clients can request data from different APIs
in a single query. It also allows to add links between these schemas
to e.g., automatically resolve references to actual types.
This first implementation was made with the following goals/limitations
in mind:
- I tried to avoid interfering with existing code and to stick to
existing architecture where possible
- I tried to avoid introducing new dependencies for existing users of
the library; in particular, kgraphql core should not get any ktor
specific dependencies
- I tried to have the stitching API as lean as possible
- I focused on the non-experimental `ParallelRequestExecutor` first
Over the course of implementing schema stitching, several bugs were
resolved on the way but schema stitching is currently still impacted
by some major issues like incomplete error handling (#114) that need
to be addressed separately.
Resolves#9
According to the spec, there is a distinction between "request errors" and "field errors" (and it would most likely make sense to have that distinction in our code base as well).
Field errors must result in a partial response, i.e. a response with
data
entry and all (unique) raised field errors in theerrors
entry. If a field error occurs on a nullable field, the value of that field will be coerced tonull
. Otherwise, the error propagates to the parent field where it will be handled similarly (if the parent is nullable, it will be coerced tonull
, otherwise the error propagates further).Consider the following schema:
Happy case:
Result:
Error case:
Result:
Expected would IMHO be a partial response along the lines of:
IMHO incorrect error handling should be considered a bug but there is definitely potential for related enhancement as well.
See
The text was updated successfully, but these errors were encountered: