Previously, an operation like this would pass validation:
query {
field(listArg: [$undefinedVar])
}
It turns out this is not very common as we haven't seen this cause a problem
on hundreds of thousands of operations. But it does happen :)
This moves the UndefinedVariable rule to value validation: we are already
recursing into the value here, and we're actually also already checking
that the variable exists, so this is a simpler place to do it than in
the variable.rs module.
This fixes the immediate problem. There are two things that I may be able to
address here before we merge it time willing...
[ ] We are validating the type of variables passed directly to arguments in variable.rs, but the type of a variable used inside a nested value inside value.rs, and both ways are different? Is this correct according to spec or should it be changed?
[ ] There is a TODO in this code that seems valid and this might be a nice time to do it
Previously, an operation like this would pass validation:
It turns out this is not very common as we haven't seen this cause a problem on hundreds of thousands of operations. But it does happen :)
This moves the UndefinedVariable rule to value validation: we are already recursing into the value here, and we're actually also already checking that the variable exists, so this is a simpler place to do it than in the
variable.rsmodule.This fixes the immediate problem. There are two things that I may be able to address here before we merge it time willing...
variable.rs, but the type of a variable used inside a nested value insidevalue.rs, and both ways are different? Is this correct according to spec or should it be changed?