You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
@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?
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
prepare
d 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 incontext
and then remember to check forcontext[: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 aprepare
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?The text was updated successfully, but these errors were encountered: