Max query depth called later in beginExecuteOperation#2773
Conversation
…wn in MaxQueryDepthInstrumentation
…w are called at execution time not after validation
| @Override | ||
| public InstrumentationState createState(InstrumentationCreateStateParameters parameters) { | ||
| return new State(); | ||
| } |
There was a problem hiding this comment.
Only needed so we can capture InstrumentationValidationParameters parameters to maintain API
| instrumentationContext.onCompleted(null, new RuntimeException()) | ||
| then: | ||
| 0 * queryTraversal._(_) | ||
|
|
There was a problem hiding this comment.
These no longer make sense since we dont go via validation anymore
| 0 * queryTraversal._(_) | ||
|
|
||
| } | ||
|
|
There was a problem hiding this comment.
Again does not make sense any more as wel dont do work on validation
|
This fixes #2811 |
| } | ||
| State state = parameters.getInstrumentationState(); | ||
| // for API backwards compatibility reasons we capture the validation parameters, so we can put them into QueryComplexityInfo | ||
| state.instrumentationValidationParameters = parameters; |
There was a problem hiding this comment.
this could be read in another Thread I think. Therefore instrumentationValidationParameters would need to synchronized or Atomic I think
There was a problem hiding this comment.
fixed - in reality it would not be a problem since the 2 methods are called within the same thread - but hey - I fixed it anyway
andimarek
left a comment
There was a problem hiding this comment.
see my comment for one question / concern
> This bug fix release contains an important fix > [#2773](graphql-java/graphql-java#2773) > The latest 18.0 version of graphql-java changed the way raw values are resolved to canonical values. > However this revealed a bug in MaxQueryXXX instrumentation where invalid values (null being present for non nullable input values) > caused an exception rather than generating a graphql error. This is not a behavior we intended. > The bug is only present if you use graphql.analysis.MaxQueryDepthInstrumentation and graphql.analysis.MaxQueryDepthInstrumentation https://github.com/graphql-java/graphql-java/releases/tag/v18.1
> This bug fix release contains an important fix > [#2773](graphql-java/graphql-java#2773) > The latest 18.0 version of graphql-java changed the way raw values are resolved to canonical values. > However this revealed a bug in MaxQueryXXX instrumentation where invalid values (null being present for non nullable input values) > caused an exception rather than generating a graphql error. This is not a behavior we intended. > The bug is only present if you use graphql.analysis.MaxQueryDepthInstrumentation and graphql.analysis.MaxQueryDepthInstrumentation https://github.com/graphql-java/graphql-java/releases/tag/v18.1
Previously the MaxQuery depth instrumentation was called on the end of the validation step. But this is too early if there are null / non null variables mismatched. This caused and exception to be thrown and not a graphql error.
We now call the instrumentation during the
beginExecuteOperationwhich is JUST before execution proper and not after validation - because theExecutioncode does some more sensibility checks on the state of the callI started this branch from #2763 which showed the problem happening
I am leaving that PR so we can improve the error messages - but this PR fixes the actual problem in the sense query checks are done a smidge later and avoid the problem all together