Required errors collection for mutation conventions

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.

Start with the mutation errors documentation linked in the issue and the existing mutation conventions built on interceptors. Clarify whether the goal is required error-array nullability, configurable nullability, IsSuccess/IsError fields, or usage guidance. Done should be a decided scope with documented behavior or an agreed implementation path.