Skip to content

Exception handeling in query #1410

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

Closed
nrbnlulu opened this issue Mar 16, 2022 · 1 comment
Closed

Exception handeling in query #1410

nrbnlulu opened this issue Mar 16, 2022 · 1 comment

Comments

@nrbnlulu
Copy link

nrbnlulu commented Mar 16, 2022

#513

all the solution mentioned in this issue are for mutation, is there a way to send custom output for a query?

I am trying to handle permissions for different queries and have decorators that
will filter premonitions from resolver example code would be like this:

class OutputMixin:
    """
    A class to all public classes extend to
    padronize the output
    """

    success = graphene.Boolean(default_value=True)
    errors = graphene.Field(ExpectedErrorType)


class ServerStatusType(DjangoObjectType, OutputMixin):
    class Meta:
        model = models.ServerStatusRecord



def admin_only(fn):
    def wrapper(root, info  *args, **kwargs):
        user = info.context.user
        if user.is_admin:
            return fn(*args, **kwargs)
        return cls(success=False, errors=Messages.NOT_VERIFIED)

    return wrapper


class StatusQuery(graphene.ObjectType):
    current_status = graphene.Field(ServerStatusType)


    @admin_only
    def resolve_current_status(cls, root, info, **kwargs):
        return models.ServerStatusRecord.objects.latest()

While this code works flawlessly with mutations it doesn't work with queries
because the the resolve function isn't accepting the object type as the first argument
the object exists under info.return_type.graphene_type(success=False, errors="fdsaf")
but its seems like a terrible hack and all the fields are required so i cant return just that.

@erikwrede
Copy link
Member

erikwrede commented Apr 1, 2022

Is there a specific reason for you to use a custom type for errors instead of referring to the inbuilt exception handling?
When you throw an exception in graphene, these errors are incorporated into your response:

{
    "data": {
       your response data/query data
    },
    "errors": [
        {
            "message": "Exception",
            "locations": [
                {
                    "line": 2,
                    "column": 3
                }
            ],
            "path": [
                "name of your query/mutation"
            ]
        }
    ]
}

Your wrappers could look like this:


def admin_only(fn):
    def wrapper(root, info  *args, **kwargs):
        user = info.context.user
        if user.is_admin:
            return fn(*args, **kwargs)
        raise GraphQLError(Messages.NOT_VERIFIED)

    return wrapper

The advantage of this approach is, that clients like Apollo support error handlers for this notation by default.

This does also work for queries, but you have to annotate the resolvers correctly.
If for other reasons you still want to stick to your approach, please send an example that includes a query that is also annotated. Maybe I can help you find the reason of failure then.

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

No branches or pull requests

2 participants