Improve Error Handling

[jhgg]

Initial discussion started in #31 -

graphql-core's exception handling is lacking. I'd like to implement a way where we can forward resolver errors to some place where they can be appropriately captured with their traceback in-tact.

It should handle sync and async resolver errors just the same.

[inklesspen]

Agreed; the 'except Exception' stuff is particularly prone to obscuring the actual problem; to find the problem in graphql-python/graphene#50 I needed to edit the graphql-core source and put in some pdb calls

[Globegitter]

Is there any update on this? Been running into issues a few times now where a stacktrace would have been very useful. Also happy to look into it with some pointers.

[jhgg]

@Globegitter - will probably be over the winter vacation time. I'm very busy at my new job ;(

[Globegitter]

@jhgg If you can give me any pointers as to where a good place is to start I would be happy to try and look into it.

[jdugan1024]

@Globegitter I didn't dig into this too deeply yet, but I believe at least part of the problem is here:

https://github.com/graphql-python/graphql-core/blob/450620de817480e5f36b64b7eb055a2be12abea0/graphql/core/execution/executor.py#L195-L197

I'm not clear enough on the internals to understand the flow of control or how one might expose the errors in the ctx object.

[defrex]

Any movement on this? It's massively problematic for me.

The ideal solution for me would be no solution. I already have error handling at the application layer that would turn the requests into 500s and appropriately log the traceback. Having a whole other way of managing errors seems unnecessary.

That said, anything would be better then the way it is now. As things stand debugging production errors is essentially impossible.

There is also a potential security issue with sending even the message line of the traceback to the user, as it could contain sensitive information.

[jdugan1024]

I agree, we need something better than the current nothing. ;-)

There is pull request #47 which was submitted by @rafales a while back. It just uses the logging module to report errors. I'm doing something similar in my dev environment. I think #47 is a good start and probably should be implemented until there is a better solution. This sidesteps the security issues for now as well.

There should be a hook so as a developer I can provide some kind of feedback to the user that something went wrong. Silently swallowing errors and returning None is very confusing.

If I get some time I'll see if I can work up an actual solution, but I'm not sure when I'll have the time.

[jhgg]

If I get some time I'll see if I can work up an actual solution, but I'm not sure when I'll have the time.

I'm in the same boat. Let me see what I can do quickly over the weekend to get out 0.4.12.2 w/ better error logging.

[syrusakbary]

This is fixed in the master branch now by the commits: f2175f5, 0143e08.

All the GraphQLErrors now also have a stack that corresponds with the stacktrace of the original Exception, and a original_error field pointing to the original error.
Also, a exception is logged in the logger each a exception is raised.

Closing this issue.

[marcelombc]

I don't think this is working. Every time I access the stack from GraphQLLocatedError the stack is None. It seems that when accessing sys.exc_info()[2] the error was already been handled and is no more on the stack.
I created a workaround by creating a decorator to handle exceptions and add stack property to the original error. Then in my CustomGraphQLView I could print the traceback properly. This way it's easy to track where the error happened

Decorator:

def handle_exceptions(f):
    @wraps(f)
    def wrapper(*args, **kwargs):
        try:
            return f(*args, **kwargs)
        except Exception as e:
            e.stack = sys.exc_info()[2]
            raise e
    return wrapper

My custom graphql view:

class CustomGraphQLView(GraphQLView):
    def execute_graphql_request(self, *args, **kwargs):
        """Extract any exceptions and send them to sentry and django log"""
        result = super(GraphQLTokenView, self).execute_graphql_request(*args, **kwargs)
        if result.errors:
            for error in result.errors:
                try:
                    if hasattr(error, 'original_error'):
                        raise error.original_error
                    raise error
                except Exception as e:
                    sentry_client.captureException()
                    if hasattr(e, 'stack'):
                        traceback.print_tb(e.stack)
                    logger.exception(e)
        return result

[tony]

Related: https://github.com/graphql-python/graphql-core/issues/237, graphql-python/graphql-core#209, graphql-python/graphql-core#202

After viewing the issue tracker, I'm not sure if there is a best practice for handling errors at the core level.