Skip to content

Required errors collection for mutation conventions #8452

@WORMrus

Description

@WORMrus

Product

Hot Chocolate

Is your feature request related to a problem?

I'm not sure how to best report this, as it falls somewhere between a bug, a question, and a feature request. So, apologies if this is not the correct form.

Our project requires returning a non-nullable array of errors in each mutation response. We also need an IsSuccess flag. So something like this:

type CreateProductResult {
  errors: [BaseError!]!
  isSuccess: Boolean!
  product: Product
}

There is also a custom error type, but I believe this is already configurable.

So, looking at the docs, we can see that "conventions also allow you to create mutations that follow the error stage 6a Pattern Marc-Andre Giroux laid out". Following this link, we can see that the article proposes a non-nullable array of errors: userErrors: [CreateUserError!]! (this is where the "possibly a bug" is coming from).

It does not propose the use of IsSuccess, but I found that 'FieldResult' (formerly 'MutationResult'), which is, as I understand, a type tightly connected to mutation conventions, does have that field.

I considered reimplementing mutation conventions with that important '!' in mind, but found that the existing implementation is built on interceptors, which are not meant to be used by users. For that reason, I am not exactly sure how I could proceed here.

The solution you'd like

So, based on whether this is a bug, a reasonable feature request, or a question, it would be nice if you could:

  • Fix the bug making the errors required
  • Allow configuring the nullability of the errors array. It would be nice if it also had IsSuccess\IsError properties
  • Provide some helpful guidance on how this can be achieved. Since interceptors are 'forbidden', I'm not sure what I can do to override a returning type programmatically for all mutations.

Metadata

Metadata

Assignees

No one assigned

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions