Is there a way to set custom error status codes?

[GasimGasimzada]

I am using Graphene Django and I am not able to find a way to respond with a custom status code (e.g 401, 403 etc). What is the correct way for me to implement this? Even if I throw an exception, the received response code is still.

[ekampf]

You shouldn't be using http error codes with GraphQL but the GraphQL.
For unexpected errors you should look at the response's errors array.
Expected errors should be described in the schema.

For example lets consider 401 error on a viewer query, I would have it return a union:
viewer: Viewer | UnauthenticatedError

Client query would look like this:

{
  viewer {
    type: __typename
    ... on Viewer { someField }
    ... on UnauthenticatedError { reason }
  }
}

Then on the client you can decide what to do based on the type you get

[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.

[berkcoker]

I think in the case of token authentication, it would make sense to be able to return a 401, even if only one field errors out this way. This status code is necessary to make this library compatible with authMiddleware in React Relay Network Modern, which expects a 401 status code to refresh tokens.

[belkka]

For example lets consider 401 error on a viewer query, I would have it return a union: viewer: Viewer | UnauthenticatedError

@ekampf could you, please, provide a real-world example of app using this approach? I'm looking for inspiration how to implement it for majority of queries and mutations in the app without blowing up the codebase.

[belkka]

BTW, another disadvantage of not setting http status code is not being able to distinguish logical 4xx client errors and 5xx server errors. For example, I would like to configure Sentry error capturing in a such way, that it ignores client errors (bad requests that do not indicat an issue) but does capture server errors. All exceptions look the same for graphene.

But this problem is rather related to graphene_django.