Let's say you're writing an application with the common Yoga/Binding/Prisma stack:
+-----+ +------------+ +---------------+ +------+
| App |---|GraphQL Yoga|---|GraphQL Binding|---|Prisma|
+-----+ +------------+ +---------------+ +------+
This has many benefits as better flexibility and less code, but makes locating GraphQL Errors right now pretty hard. That's the case, because in this stack we have 3 GraphQL Schemas that are involved to process a query.
GraphQLSchema from graphql js.Let's say we get a response like this: (taken from https://github.com/graphcool/graphql-server-example/issues/92)
{
"data": null,
"errors": [
{
"message": "Field 'places' of type 'Place' must have a sub selection. (line 2, column 3):\n places(where: $_where, orderBy: $_orderBy, skip: $_skip, after: $_after, before: $_before, first: $_first, last: $_last)\n ^",
"locations": [
{
"line": 2,
"column": 3
}
],
"path": [
"homesInPriceRange"
]
}
]
}
We now know that a subselection is missing. We suspect this error to occur in either the Yoga schema or the binding schema. But where did it actually happen? We don't know.
This is a simple example, where only one source is used in Yoga. There could be hundreds of microservices used by Yoga, where the overview would be totally lost. We need a solution for this.
In order to know where an error comes from, we could add a property to it, that describes its source.
Right now the spec for the error type looks like this:
type Error {
message: String!
path: [String!]
location: [Location!]
}
In Prisma we added 2 more properties, requestId and code:
type Error {
message: String!
path: [String!]
location: [Location!]
requestId: String!
code: Int
}
The proposal is, too add a property called source: String. In our example from above, it would look like this:
{
"data": null,
"errors": [
{
"message": "Field 'places' of type 'Place' must have a sub selection. (line 2, column 3):\n places(where: $_where, orderBy: $_orderBy, skip: $_skip, after: $_after, before: $_before, first: $_first, last: $_last)\n ^",
"locations": [
{
"line": 2,
"column": 3
}
],
"path": [
"homesInPriceRange"
],
"source": "yoga"
}
]
}
Now we can see, that the error has been triggered in the yoga schema.
This is a rough proposal, how a solution for finding the error source could look like.
If you're interested in working on this, please let us know in a comment or join our public Graphcool Slack!
@timsuchanek i'd be happy to work on this. Feeling the pain right now trying to debug missing sub selection errors and something like your proposal would be very helpful.
Extending the original proposal, what we essentially want to do is to recursively preserve the errors from graphql spec for multiple schemas across a delegation path.
This can be achieved by adding delegrationErrors and schemaId key to error extensions.
delegationErrors will recursively capture all errors across the delegation path and preserve them in a similar structure to the errors field.
schemaId will be a string/url as a unique identifier for any schema on the delegation path.
An example response of graphql server implementing such a sources solution would look like this:
{
"errors": [
{
"message": "Name for character with ID 1002 could not be fetched.",
"locations": [{"line": 6, "column": 7}],
"path": ["hero", "heroFriends", 1, "name"],
"extensions": {
"schemaId": "schema_1",
"code": "CAN_NOT_FETCH_BY_ID",
"timestamp": "Fri Feb 9 14:33:09 UTC 2018",
"delegationErrors": [
{
"message": "Name for character with ID 1002 could not be fetched.",
"locations": [{"line": 6, "column": 7}],
"path": ["hero", "heroFriends", 1, "name"],
"extensions": {
"schemaId": "schema_2",
"code": "CAN_NOT_FETCH_BY_ID",
"timestamp": "Fri Feb 9 14:33:09 UTC 2018"
}
}
]
}
}
]
}
I'm having a hard time dealing with my errors from Prisma as they aren't machine readable. Please fill the extensions key with useful infos (code, path, field...). 馃檹
This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 10 days if no further activity occurs. Thank you for your contributions.
Most helpful comment
Extending the original proposal, what we essentially want to do is to recursively preserve the
errorsfrom graphql spec for multiple schemas across a delegation path.This can be achieved by adding
delegrationErrorsandschemaIdkey to error extensions.delegationErrorswill recursively capture all errors across the delegation path and preserve them in a similar structure to theerrorsfield.schemaIdwill be a string/url as a unique identifier for any schema on the delegation path.An example response of graphql server implementing such a sources solution would look like this: