-
Notifications
You must be signed in to change notification settings - Fork 1.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
Add input path in unmarshaling errors #1115
Add input path in unmarshaling errors #1115
Conversation
6ac4b6b
to
fd615cf
Compare
I was thinking now that this is, in a way, a breaking change because some implementations might be expecting the old pat somewhere downstream. So this feature could be enabled through configuration so you can switch between the partial field path or the full path for the errors. |
An extension to this that I would like to make and I didn't handle in this PR would be to not fail on the first unmarshal error in the arg tree, but collect all errors in the tree using a |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
a8530f3
to
bde4291
Compare
Thanks, this has annoyed me for a long time. 🎉 I've added a small commit to drop the custom context names to be consistent with the rest of the context usage (eg field context). |
…haling Add input path in unmarshaling errors
Problem summary
When relying on custom scalar, especially in mutations, you offload an aspect of validation to the unmarshaling step. This means that you ensure these custom types have the right structure in one place and then you can rely on them in the next layers.
The problem with the current implementation is that errors that happen as a result of scalar unmarshaling only have path information up to the mutation that they occur in. And it's impossible to reconstruct what field in the input is responsible for the error if you have multiple instances of the scalar in a nested input structure. And makes it impossible for the frontend to link the error to a form field, for example.
Solution
I've added a new context type
FieldInputContext
which acts similarly toFieldContext
but is responsible for keeping track of the nesting inside of the arguments received by queries or mutations. This context is then used during unmarshaling to wrap the error returned into agqlerror.Error
if it's not already or just inject thepath
if it is. This lets developers returngqlerror.Error
from their unmarshaling logic in order to inject additional data inextensions
See the updated docs for additional details.
Codegen touchpoints:
args.gotpl
- created nested input context for each argumentinput.gotpl
- created nested input context for each field in an inputtype.gotpl
- treat all unmarshaling scenariosI have: