Error handling

[sebastiandev]

We have decided to approach error handling like suggested in many blogs, by having errors defined as fields rather than raising exceptions.

The thing with this is that we need to make sure we catch every exception that we want to handle and somehow keep track of them to be able to inform them.

So we came up with:

class BaseObjectType(graphene.ObjectType):

    class Meta:
        abstract = True

    @classmethod
    def __init_subclass_with_meta__(
        cls,
        interfaces=(),
        possible_types=(),
        default_resolver=None,
        _meta=None,
        **options
    ):
        super().__init_subclass_with_meta__(
            interfaces, possible_types, default_resolver, _meta, **options)

        for f in cls._meta.fields:
            if f in ['errors']:
                continue

            resolver_name = "resolve_{}".format(f)
            if hasattr(cls, resolver_name):
                setattr(cls, resolver_name, catch_errors(getattr(cls, resolver_name)))


class BaseResponse(BaseObjectType):

    class Meta:
        abstract = True

    errors = graphene.String()

    @staticmethod
    def resolve_errors(root, info, **kwargs):
        operation_name = info.path[0]
        error_key = f"{operation_name}_errors"
   
        if not root.errors and error_key in info.context.errors:
            root.errors = ",".join(info.context.errors[error_key])

        return root.errors

catch_errors just populates info.context.errors for each operation

While implementing this approach for error handling I have also found an issue when resolving the error field. I have a base class that extends ObjectType by iterating over the resolvers and wrapping them to n catch any errors and setting an errors dict in the info.context.

Problem is that when resolving a type field that throws an exception, I do catch it and set the error, but the error field was already processed/resolved. Is there a way to force a particular field to be processed at the end or to force it to update? I need to make sure every resolver runs before the error field is resolver so I make sure all errors are caught.

[BossGrand]

This is possible! You need to wrap the resolver like such

def wrap_resolver(cls, resolver):

    def wrapped_resolver(root, info, **args):
        try:
            with transaction.atomic():
                return resolver(root, info, **args)

        except Exception as e:
            return cls(errors=str(e))

    return wrapped_resolver


class CustomMutation(Mutation):

    class Meta:
        abstract = True


    @classmethod
    def __init_subclass_with_meta__(cls, resolver=None, **options):

        if not resolver:
            mutate = getattr(cls, 'mutate', None)
            assert mutate, 'All mutations must define a mutate method in it'
            resolver = get_unbound_function(mutate)
            resolver = wrap_resolver(cls, resolver)

        super(CustomMutation, cls).__init_subclass_with_meta__(resolver, **options)

        cls._meta.fields['errors'] = (Field(String, name='errors'))

Then you use CustomMutation as class that all your Mutations will subclass. This wraps the resolver and catches any exceptions. In my own implementation I have a custom Exception class that i'm looking for. But thats up for you to decide

[sebastiandev]

@BossGrand yes, for mutations it works, and I solved it in the same way, but for queries doesn't work. That's the main problem, having to check errors differently for mutations and queries is not a good user experience.

So to keep them consistent we need to have a errors field for queries as well, if the root response cannot be extended, then subclassing ObjectType and adding an errors field, and use the custom ObjectType as the base type for every query result.

Queries may fail, but also, the resolvers of each field from the query response may fail, so you need a way of catching any of those errors, and some how populate the error field with them. Problem is you don't control when fields are resolved, thus cannot force the error field to be resolved at the very end to make sure all the other resolvers were executed and catched (if they errored).

Its a bit confusing, but hopefully you got the idea.

[BossGrand]

what type of errors do you expect to get via queries?

[sebastiandev]

Well queries are resolved in many different ways, from different microservices, so errors can happen.
Like unauthorized access to a resource, bad search input (which is not strictly typed), and some complex queries that might return domain errors. I just don't think having to check in 2 places for errors is convenient for the user. So you use the errors payload or have a errors field on each query/mutation, but not both.

[jeanlucmongrain]

I'm actually struggling trying to do the same thing with queries

I created a query that I can pass a django form to perform validation and return errors like the mutation of django integration

but the problem is that, returned value is considered as a normal response

[jeanlucmongrain]

what type of errors do you expect to get via queries?

class Query(graphene.ObjectType):
        credit_card=graphene.String(
            required=True,
            description="Which CC to use"
        )

if the value is an invalid CC, like 1234, we need something like:

errors: [
  {"type":"credit_card", "messages":["invalid credit card number"]}
]

i know we could just use an enum, but

[sebastiandev]

So, just for the record, @bclermont I went with the decorator approach, catching every possible error on both queries and mutations (using a base class for both that wraps every resolver). In the error handler decorator I just catch, format and re-raise errors and finally in the global error handler I decide what data to output in the errors payload, depending on the type.
I gave up with the errors field approach as is not possible to use it for queries.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[flowirtz]

Thanks for clarifying, @sebastiandev.

I'm still interested how other people do this: Is anybody approaching a more middleware-esque approach on a higher graphene level? Am having quite a few resolvers and don't want to be adding decorators to all of them, if avoidable.

[sebastiandev]

@fwirtz if you just subclass ObjectType and use your custom class as a base for all you queries/mutations, it will automatically wrap all your resolvers, and you wont need to care about missing a resolver or anything. That's how I did it

def catch_errors(func):
    f_data = inspect.signature(func)

    if not 'info' in f_data.parameters.keys():
        raise ValueError(f"Resolver {func.__name__} is missing the info parameter")

    @wraps(func)
    def wrapper(*args, **kwargs):
        info = None
        for arg in list(args) + list(kwargs.values()):
            if isinstance(arg, graphql.execution.base.ResolveInfo):
                info = arg

        try:
            res = func(*args, **kwargs)
            return res
       except Exception as e:
           # your code for error handling here...


class BaseObjectType(ObjectType):

    class Meta:
        abstract = True

    @classmethod
    def __init_subclass_with_meta__(
        cls,
        interfaces=(),
        possible_types=(),
        default_resolver=None,
        _meta=None,
        **options
    ):
        super().__init_subclass_with_meta__(
            interfaces, possible_types, default_resolver, _meta, **options)

        for f in cls._meta.fields:
            resolver_name = "resolve_{}".format(f)
            if hasattr(cls, resolver_name):
                setattr(cls, resolver_name, catch_errors(getattr(cls, resolver_name)))

for mutations you can apply a similar approach, I have a different code since we have built a layer on top of graphene to have mutations as plain classes (to group mutations methods in one class, and other goodies..)

[clin88]

Bump on this issue.

Error handling is a big deal when implementing any API and graphene's middleware doesn't offer any obvious way to do this.

A very common use case is catching all exceptions and stripping any internal error handling. This is crucial for security purposes: it's not uncommon for stringified exceptions to have PII and other sensitive information.

The only way to do this in graphene is to decorate every resolver with error handling functionality or using the metaclass approach described above.

Ariadne, by contrast, treats this as a first class use case:

https://ariadnegraphql.org/docs/error-messaging

Is proper error handling somewhere on the roadmap?

[dreamawakening]

Does anyone have a workaround for this in the meantime? All exceptions raised are printed to the console during testing/development.

Some packages such as django-graphql-jwt raise exceptions for things like user authentication. Those kinds of exceptions are just for the API user to see, so it'd be nice to be able to raise exceptions without them polluting the console output.