Skip to content

Conversation

@bbakerman
Copy link
Member

@bbakerman bbakerman commented Mar 26, 2022

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 beginExecuteOperation which is JUST before execution proper and not after validation - because the Execution code does some more sensibility checks on the state of the call

I 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

@Override
public InstrumentationState createState(InstrumentationCreateStateParameters parameters) {
return new State();
}
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Only needed so we can capture InstrumentationValidationParameters parameters to maintain API

instrumentationContext.onCompleted(null, new RuntimeException())
then:
0 * queryTraversal._(_)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These no longer make sense since we dont go via validation anymore

0 * queryTraversal._(_)

}

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Again does not make sense any more as wel dont do work on validation

@andimarek
Copy link
Member

This fixes #2811

@andimarek andimarek requested review from andimarek and dondonz April 26, 2022 04:18
}
State state = parameters.getInstrumentationState();
// for API backwards compatibility reasons we capture the validation parameters, so we can put them into QueryComplexityInfo
state.instrumentationValidationParameters = parameters;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this could be read in another Thread I think. Therefore instrumentationValidationParameters would need to synchronized or Atomic I think

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member

@andimarek andimarek left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

see my comment for one question / concern

@bbakerman bbakerman merged commit b424f98 into master Apr 29, 2022
@bbakerman bbakerman added this to the 19.0 milestone Apr 29, 2022
@dondonz dondonz modified the milestones: 19.0, 18.1 May 3, 2022
berngp added a commit to Netflix/dgs-framework that referenced this pull request May 4, 2022
> 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
berngp added a commit to Netflix/dgs-framework that referenced this pull request May 4, 2022
> 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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants