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
If the field returns null because of a field error which has already been added to the "errors" list in the response, the "errors" list must not be further affected. That is, only one error should be added to the errors list per field.
(Emphasis mine.)
I am surprised by this. I think it is useful to be able to return multiple errors per field, for example if a field has multiple arguments and more than one of them are determined (during execution) to be invalid. I am unsure why the spec says this is not allowed. But I can't find any ambiguity here.
I'm OK with this being closed as "wontfix". That, however, puts the responsibility of following the spec on users, which I don't like.
Assuming this will not be fixed, I would very much like the opinions of more experienced GraphQL devs on whether breaking this part of the spec is OK or even the right thing to do.
The text was updated successfully, but these errors were encountered:
Product
Hot Chocolate
Version
14.0.0-p.93
Link to minimal reproduction
See below
Steps to reproduce
Repro solution: HotChocolateBugRepro.zip
Code for reference:
What is expected?
What is actually happening?
Relevant log output
No response
Additional context
If you now go "what?!", then I agree.
The GraphQL spec's section "Handling Field Errors" seems absolutely clear:
(Emphasis mine.)
I am surprised by this. I think it is useful to be able to return multiple errors per field, for example if a field has multiple arguments and more than one of them are determined (during execution) to be invalid. I am unsure why the spec says this is not allowed. But I can't find any ambiguity here.
I'm OK with this being closed as "wontfix". That, however, puts the responsibility of following the spec on users, which I don't like.
Assuming this will not be fixed, I would very much like the opinions of more experienced GraphQL devs on whether breaking this part of the spec is OK or even the right thing to do.
The text was updated successfully, but these errors were encountered: