[RFC] Introduce Strict and Legacy All Variable Usages Are Allowed #1059
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.
For the following schema:
The following query is currently valid:
This query will accept the variables
{"number": null}
and result in a runtime field error when it turns out thatnull
cannot be used in this non-nullable list value position. This was discussed in depth in the December 2022 Secondary EU WG meeting, resulting in this action item graphql/graphql-wg#1337. Timestamped link to the relevant part of the discussion: https://youtu.be/nkPn-F_UBJo?list=PLP1igyLx8foH30_sDnEZnxV_8pYW3SDtb&t=2702This PR implements the agreed solution: it introduces a stricter version of the All Variable Usages Are Allowed algorithm which forbids a nullable variable from being used in a non-nullable position; and to support existing documents a legacy version of the old algorithm is maintained (basically a copy/paste).
Under the new strict algorithm, the previous query becomes invalid and you'd need to make the variable type non-nullable:
This still allows the variable
$number
to be omitted, but it does not allow it to be explicitlynull
.IMPORTANT NOTE: this new algorithm does not allow an argument/input object field's default value to be used if a variable is used as the value for that argument/input object field. A workaround is to copy the argument/input object field's default value to the variable definition, but this will mean that changes to the argument/input object field's default value will not be reflected by existing queries. I think this is acceptable, since there's no way to leverage the default value of an argument when passing a literal to it either - I'm in favour of literal/variable equivalence where possible, and I think that the benefits of turning this runtime error into a validation error outweigh the costs.
cc @leebyron @mjmahone @IvanGoncharov as they were participants in the discussion above and contributed to this decision.