Skip to content
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

"Errors as data" from within prepare blocks #4574

Open
eapache-opslevel opened this issue Aug 1, 2023 · 1 comment
Open

"Errors as data" from within prepare blocks #4574

eapache-opslevel opened this issue Aug 1, 2023 · 1 comment

Comments

@eapache-opslevel
Copy link
Contributor

eapache-opslevel commented Aug 1, 2023

Is your feature request related to a problem? Please describe.

prepared arguments on mutations have no way to return errors as data; they can return a value, or they can raise an exception. Currently, we have to shove values in context and then remember to check for context[:errors].present? at the top of every single mutation.

Describe the solution you'd like

In line with the solution for authorized? (https://graphql-ruby.org/mutations/mutation_authorization.html#adding-errors) it would be nice to be able to return a mutation payload with errors from a prepare block that would halt the mutation.

Since there's no return value that couldn't theoretically be intended as the real prepared value, it might be better to designate a specific new exception, like raise GraphQL::ErrorAsData, { errors: [...] } or something.

cc my non-work account @eapache

@rmosolgo I don't know if this ends up being pretty easy or not... prepare is used for non-mutation arguments too and it's not clear how we would need to handle those. Maybe it's just considered a bug / internal error to raise that exception outside of a mutation context?

@rmosolgo
Copy link
Owner

rmosolgo commented Aug 2, 2023

👋 Hey!

I can see how this would be useful and raising an error like that makes sense to me, from a practical standpoint.

Regarding non-mutations, I think the same behavior would be OK: if such an error is raised, use it as the field's return value.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants