Fix query complexity for fragments defined after operations #1826
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes #785, test shamelessly taken from #1350
QueryComplexitycollects all field nodes and their definitions using aNodeKind::SELECTION_SETvisitor. WhenNodeKind::OPERATION_DEFINITIONvisitor was run, complexity function, on the field's definition, for each found field was executed.However, that's not enough when using fragments. When
NodeKind::OPERATION_DEFINITIONis run, field definitions for later-defined fragments have not yet been collected:Complexity function for non-collected fields (
aandb, in this case) was not run, and a fallback of value1was always used instead.This PR changes
QueryComplexityto use aNodeKind::DOCUMENTvisitor in place ofNodeKind::OPERATION_DEFINITION, as by then it's guaranteed all selection sets have been visited, and field definitions collected.There is a minor behaviour change with this - when query complexity is exceeded, an error will now be thrown later during validation than before. As error order is not part of the api contract, I assume this is acceptable.