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

fix(compiler): fix validation for undefined variables nested in values #883

Merged
merged 4 commits into from
Jul 19, 2024

Conversation

goto-bus-stop
Copy link
Member

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

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.
Comment on lines +67 to +77
Error: expected value of type Boolean, found a variable
╭─[0101_mismatched_variable_usage.graphql:51:50]
51 │ nonNullBooleanListField(nonNullBooleanListArg: [$intArg])
│ ───┬───
│ ╰───── provided value is a variable
63 │ nonNullBooleanListField(nonNullBooleanListArg: [Boolean]!): Boolean
│ ─────┬────
│ ╰────── expected type declared here as Boolean
────╯
Copy link
Member Author

Choose a reason for hiding this comment

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

I added this to show that the error message is very different depending on if you use the variable directly or nested inside a value... I think they should be treated the same

@goto-bus-stop goto-bus-stop merged commit 527bcb2 into main Jul 19, 2024
12 checks passed
@goto-bus-stop goto-bus-stop deleted the renee/FED-368-variable-usage branch July 19, 2024 15:50
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.

2 participants