We validate Apollo persisted operation manifests (CI gate for our mobile apps and web client) with DocumentValidator::validate(). A manifest contains only the operation text, so there are no variable values, but we would still like to enforce a complexity limit.
QueryComplexity cannot be used for that: it coerces the operation's variable definitions to evaluate @include/@skip (and field arguments for fields with a complexityFn), which fails for every operation declaring required variables.
Request: a supported way to compute the worst-case complexity without variable values, e.g. a flag or subclass hook where variable-conditional @include/@skip fields are counted as included and only literal @include(if: false) / @skip(if: true) are dropped.
Currently we subclass and override directiveExcludesField() to evaluate the directive arguments from the AST, but that relies on protected internals.
Related: #1730 (validation caching also has to special-case this rule).
Reported on behalf of @ruudk.
We validate Apollo persisted operation manifests (CI gate for our mobile apps and web client) with
DocumentValidator::validate(). A manifest contains only the operation text, so there are no variable values, but we would still like to enforce a complexity limit.QueryComplexitycannot be used for that: it coerces the operation's variable definitions to evaluate@include/@skip(and field arguments for fields with acomplexityFn), which fails for every operation declaring required variables.Request: a supported way to compute the worst-case complexity without variable values, e.g. a flag or subclass hook where variable-conditional
@include/@skipfields are counted as included and only literal@include(if: false)/@skip(if: true)are dropped.Currently we subclass and override
directiveExcludesField()to evaluate the directive arguments from the AST, but that relies onprotectedinternals.Related: #1730 (validation caching also has to special-case this rule).
Reported on behalf of @ruudk.