Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support 'path' in error reporting #127

Closed
jvtm opened this issue Jun 29, 2017 · 5 comments
Closed

Support 'path' in error reporting #127

jvtm opened this issue Jun 29, 2017 · 5 comments

Comments

@jvtm
Copy link

jvtm commented Jun 29, 2017

When dealing with error responses on client side, would be nice to know which field caused it. Right now there seems to be support for locations -> (column: .., line: ...), but not for the path specified in graphql/graphql-spec#230

If an error can be associated to a particular field in the GraphQL result, it must contain an entry with the key path that details the path of the response field which experienced the error. This allows clients to identify whether a null result is intentional or caused by a runtime error.

This field should be a list of path segments starting at the root of the response and ending with the field associated with the error. Path segments that represent fields should be strings, and path segments that represent list indices should be 0‐indexed integers. If the error happens in an aliased field, the path to the error should use the aliased name, since it represents a path in the response, not in the query.

{
  hero(episode: $episode) {
    name
    heroFriends: friends {
      id
      name
    }
  }
}
  "errors": [
    {
      "message": "Name for character with ID 1002 could not be fetched.",
      "locations": [ { "line": 6, "column": 7 } ],
      "path": [ "hero", "heroFriends", 1, "name" ]
    }
  ],

Note: might take a look at this at some point myself (would like to also fine-tune when server side exception prints traceback to logs and/or figuring out how to gracefully report errors to client without exception + traceback on server...)

@jvtm
Copy link
Author

jvtm commented Jun 29, 2017

Looks like graphql.error.format_error() can access nodes, positions and locations, but not sure if those would be directly usable. Not that familiar (yet :) with the code-base.

Luckily Flask-GraphQL + use_reloader=True makes experimenting quite fast.

@jvtm
Copy link
Author

jvtm commented Jun 29, 2017

A humble beginning:

diff --git a/graphql/error/format_error.py b/graphql/error/format_error.py
index 0409550..f9cdabf 100644
--- a/graphql/error/format_error.py
+++ b/graphql/error/format_error.py
@@ -7,5 +7,7 @@ def format_error(error):
             {'line': loc.line, 'column': loc.column}
             for loc in error.locations
         ]
-
+    if error.nodes:
+        # XXX: incomplete, missing (at least) the root name
+        formatted_error['path'] = [(node.alias or node.name).value for node in error.nodes]
     return formatted_error

With my simple schema right now I can only get errors on top-level fields, and error.nodes is always a list with one element.

Accidentally found a way to get the alias supported.

Missing root value name. So perhaps something needs to be patched so that GraphQLError would see the whole tree / path.

However even this small patch helps me to debug the problems more easily. My query is generated based on user request, and end-user doesn't actually know GraphQL is used (and shouldn't know about its syntax at all).

@ekampf
Copy link
Contributor

ekampf commented Oct 31, 2017

I started adding this feature at graphql-python/graphql-core#148
Would love feedback

@jvtm
Copy link
Author

jvtm commented Oct 31, 2017

I can try the patches late this week / early next week, when getting back to the related project (for graphene 2.0 upgrades)

@syrusakbary syrusakbary mentioned this issue Jun 5, 2018
@syrusakbary
Copy link
Member

Fixed in #186

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants