Skip to content
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

Max query depth called later in beginExecuteOperation #2773

Merged
merged 4 commits into from Apr 29, 2022

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

}
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.

None yet

3 participants