Discussion: Alternative Approach to Handling Mutation Errors

[humphrey]

Hi strawberry-django team,

First, I just want to say how much I appreciate the work you’re doing! I’ve been following the development of Strawberry closely, and I am already using it in a number of projects. Having just updated a couple of projects to the latest version I noticed that Strawberry is now using a generic approach to handle mutation errors, such as:

type OperationMessage {
  kind: OperationMessageKind!
  message: String!
  field: String
  code: String
}

This seems like a flexible way to handle a wide variety of errors with a minimal schema. However, since you've not yet released a 1.0 version, I wanted to start a conversation around this choice and share a different approach that I’ve found useful in production, particularly for its explicitness and flexibility. (I started using this solution before there were docs written for strawberry-django).

I use an InputError interface, which allows for specific error types like ValidationError, NotAuthenticatedError, etc.:

interface InputError {
  message: String!
}

type ValidationError implements InputError {
  message: String!
  fields: [FieldError!]!
}

type FieldError {
  field: String!
  messages: [String!]!
}

type NotAuthenticatedError implements InputError {
  message: String!
}

type NotAuthorisedError implements InputError {
  message: String!
}

type DoesNotExistError implements InputError {
  message: String!
}

# And you can create your own specific types.
type OurCustomError implements InputError {
  message: String!
  libraryId: Int!
}

I like this approach because:

• It ensures all errors have a common message field, which can be easily queried (... on InputError { message }).
• It allows for more granular error types, where I can query additional specific fields (e.g., ... on ValidationError { fields { field, messages } }).
• Using __typename on the frontend allows me to handle each error type with specific UI responses.
• Errors are strongly typed and explicit.

I’d love to hear your thoughts on the merits of both approaches. I’m curious about the design decisions that led to the current generic error handling and whether there’s room for considering more specific error types down the road. Or are there issues with my approach that make it unfeasible?

Looking forward to your thoughts and discussion!

Thanks again for all the hard work.

Upvote & Fund

• We're using Polar.sh so you can upvote and help fund this issue.
• We receive the funding once the issue is completed & confirmed by you.
• Thank you in advance for helping prioritize & fund our backlog.

[bellini666]

Hi @humphrey ,

I really like your idea! It is a lot more flexible than what we currently have

Maybe the only downside is that when writing a query that can return InputError, you need to add ... on SomeError for all possible kinds of errors in your application. Not a big deal, but something to think about.

Indeed, we haven't released 1.0 yet, so we could possibly make this breaking change. However, it is a very big change, and I'm afraid of how much it would break for people already relying on the current API, especially because it changes not only for the backend but also for the clients using the API.

@patrick91 pinging you to check your thoughts on this