-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Returning multiple errors #205
Comments
Interesting. I'm curious what the use case is. I'm concerned about the burden this would put on the execution logic, but would entertain a PR here. |
👍 We potentially have a At the moment we we map through our Promise array, catch and setup the error rather to be returned rather than thrown so we can eventually filter out and throw the array from the mutations Is there way from a mutation From GraphQL Schema 7.2.2: |
Sorry for the lack of activity here. @leebyron one use case is custom validation, for example in mutations. In Reindex we have I think a simple solution could be to create a new error type - 'GraphQLMultipleError', which accepts list of errors, and then just manage that at top level of the graphql resolve function, converting it to multiple errors there. This way we won't make the logic overly convoluted, but still allow outputting multiple errors to the user. |
Interesting - for custom validation, would it be possible to use the validator phase for this, which supports multiple errors per step? Do you need to execute the query to understand the issues, or can issues be determined statically? |
@leebyron I ran into it and searched for it and I came here. Basically I need to validate an input type based on some rules defined in the database, so the validation is at runtime. I wrote the validation function which is kind of tied to all the resolver functions. It validates the input and if all the rules are passed, it runs the resolver function. It would be nice to have a way of throwing multiple errors if multiple fields fail on the validation (or perhaps a field doesn't pass multiple rules). What I actually have done is I wrote a
|
Just to share my trial, I've ended up using custom error approach in combination with In mutation resolver I handle validation and throw the error if any:
In error handler you can check if the error isJoi or just return details of originalError:
On client you get one error (validation error), but you can access the details and display it in UI. |
@jakubknejzlik Thanks for that. I have adopted the |
@julienvincent Could you explain how you do that, please? (i asked a related question here ) |
@francoisromain according to the referenced PR, looks like you can return an array of |
@julienvincent the referenced PR is in graphql-ruby |
@leebyron Use case A resolver hits a number of back end services that may each complete successfully, or error out. In my resolver, I use Promise.allSettled and accumulate an array of errors at the end. I would like to use the built in error handling characteristics of client side solutions such as Apollo to be able to act on those errors. I have no way of generating multiple errors per resolver (or rather post processing the errors with formatError to add multiple errors to the errors array). I think in my case, it might be a little outside the scope as I want to have partial results and errors from a single endpoint, but some imperative way to add errors would be a useful way to handle this case and others. |
Hello! Has there been any progress with this issue? I'm running into the same problem, but it seems like interest here has slowed down. |
Related #3192 |
Recent patch added ability to return
Error
fromresolve
to indicate failure. In a scenarios where validation happens in theresolve
, it would be useful to be able to return multiple errors from one resolve.I am not sure what would be the best way to do it, but otherwise I am willing to implement it. One way I see is to always check if result is a array and then check if elements of that list are all
Errors
.The text was updated successfully, but these errors were encountered: