execution path propagation for better execution errors#304
execution path propagation for better execution errors#304dllx wants to merge 1 commit intographql-java:masterfrom
Conversation
|
Hi @dllx. Thank you for this! I just wrote some comments on my async execution strategy PR that stated the need for such a path mechanism. However, I also think error handling more broadly needs to be fixed in light of #268. And I'm not sure how to do it for all the execution strategies that are currently in the project. What do you think? |
|
I'm not (yet) convinced that keeping track of the path is necessary for error handling and null propagation on non-nullable fields. I have a vague idea, but don't know if it will work out. Unfortunately, I'm rather time constrained, but will have another look when possible. |
|
I like this idea in general by the way. Being able to examine errors better is a real win. |
|
Why not add it to the context? I use this approach ( nested contexts ) in my Reactive GraphQL - works great :) |
| } | ||
|
|
||
| private static class StringPathComponent implements PathComponent { | ||
| private final String value; |
There was a problem hiding this comment.
please expose value; it can be usable for other things like change tracking (my case)
|
@bbakerman could you have a look at this PR and how it relates to #499 ? thanks |
|
This has now be implemented by another PR, using this one as the starting point for the work Thanks for making this contribution |
5 participants
This patch adds execution path information to the ExceptionWhileDataFetching errors in the GraphQL result.
During execution, the path of the currently resolved/processed field is remembered and put into the ExceptionWhileDataFetching exception when an error occurs. When examining the ExecutionResult after execution is finished, each execution error can then much better be associated to the result field (which was nulled) where the error happened.
The path is in hierarchical form, with / as object field separator and with list index in square brackets, for example:
field/subField[2]/subSubFieldThe path information is an additional field in ExceptionWhileDataFetching which can be ignored if not used. So, this patch should be backward compatible.
Note: I don't understand the Batched execution strategy, so I'm not sure if I implemented it correctly there, but I think the Simple and Executor strategy are ok.