Apollo-server: How to return array of errors in one response?

[kunhuangau]

The response payload could contains an array of errors. Just wondering how can I simulate to return more than one errors in one response?

I'm using apollo-server in lambda and tried throw errors in two different resolvers, I added some debug console.log, those two resolvers have been executed, but one get one error in the response.

Thanks!

[gastonmorixe]

+1
I have been unable to return an array of errors for custom validations. I tried throwing an Error with an array of errors property as this SO answer but it doesn't seem to work for me.

[gastonmorixe]

Well it doesn't seem to be possible. After this commit error flattening was removed. https://github.com/apollographql/apollo-server/commit/19478920e4a6bdbf57b10ddc782e685542fd9bd4

Today's code these lines forces to map from the original error array, therefore I can't think any work-around to flatten the final array from the formatError callback. Maybe there's a way to do this in a plugin? I haven't found a way yet.

https://github.com/apollographql/apollo-server/blob/19f01083ea6aa5a66a1619741c70d2e453f7f264/packages/apollo-server-errors/src/index.ts#L283-L285

[gastonmorixe]

I'd like to understand what's the point of returning an error array if it's always forced to return one element.

[glasser]

@gastonmorixe In what context do you mean "return an error array"?

[gastonmorixe]

@glasser I want to return a flat array of ValidationError. Imagine a form with N validations and Y fields failing, IMO it should simply return errors: [ {err1} , {err2} ] not errors: [ [ {err1} , {err2} ] ]

isn't that nested array unnecessary?
what's the reason to completely forbid it from returning a custom "errors" payload from a custom formatter? or there is a way to do it that I missed?

Thank you

[glasser]

Sorry, to clarify, my question is the following. Is your concern:

• (a) Apollo Server encourages me to throw/return an array of errors in some context (of which @glasser is unaware) but it doesn't really work well (ie, a "bug report")
• (b) I want to return multiple errors from a single resolver and Apollo Server doesn't even try to let me do this (ie, a "feature request")

(And I will reiterate that in the apps I've worked on, when we need a lot of complexity around errors like the ability to return lots of validations failing to be rendered in the UI, I've been happier making that an actual part of the field's return value rather than part of the out-of-band error functionality.)

[glasser]

(I think if we want to do this, the best approach would be to offer a specific MultipleErrorsError or something that you can throw and that gets flattened, rather than doing some sort of magic auto flattening.)

[gastonmorixe]

Hey @glasser thank you for your detailed and prompt response.

I'd say option b. While we may agree or disagree on how errors should be handled, if the official GQL spec doesn't specify a 1-1 match between the index of the errors and the resolvers then I don't agree Apollo Server should force the devs to a nested array. At least there should be a way to opt out. I thought that was what formatError was for but it's even too late for that to help as explained above.

Thank you

[glasser]

I mean, I think the concern is that the mechanism we've used for expressing "resolving this path has an error" is "the resolver throws an error", and a resolver can't throw more than one error.

I'd be happy to review a PR that adds an explicit way of indicating "this resolver is failing with multiple errors"; I think something like throw multipleErrors(e1, e2, e3) could be a reasonable way to do that (with multipleErrors as a function, or maybe a particular error class).