SPEC/BUG: Ambiguity with null variable values and default values #1274

This change corresponds to a spec proposal which solves an ambiguity in how variable values and default values behave with explicit null values. Otherwise, this ambiguity allows for null values to appear in non-null argument values, which may result in unforseen null-pointer-errors. This appears in three distinct but related issues: **VariablesInAllowedPosition validation rule** The explicit value `null` may be used as a default value for a variable, however `VariablesInAllowedPositions` allowed a nullable type with a default value to flow into an argument expecting a non-null type. This validation rule must explicitly not allow `null` default values to flow in this manner. **Coercing Variable Values** coerceVariableValues allows the explicit `null` value to be used over a default value, which can result in flowing a null value to a non-null argument when paired with the validation rule mentioned above. Instead a default value must be used even when an explicit `null` value is provided. **Coercing Argument Values** coerceArgumentValues allows the explicit `null` default value to be used before checking for a non-null type. This could inadvertently allow a null value into a non-null typed argument.

This preserves the behavior of explicit null values taking precedence over default values, greatly reducing the scope of breaking changes. This adds a change to argument coercion to enforce null checking on variable valuesand removes one validation rule: VariablesDefaultValueAllowed. This allows supplying default values to non-nullable variables, widening the gap between "required" and "nullable". It also changes the validation rules for arguments - allowing non-null arguments with default values to be omitted. This preserves all existing behavior (with the critical exception of no longer allowing `null` values into non-null arguments) while allowing queries which were previously considered invalid to be valid.

This is now *a breaking change*. The default validation rules are stricter, however with a configuration flag the previous lax behavior can be used which will ensure an existing service can support all existing incoming operations. For example to continue to support existing queries after updating to the new version, replace: ```js graphql({ schema, source }) ``` With: ```js graphql({ schema, source, options: { allowNullableVariablesInNonNullPositions: true }}) ``` Another more minor breaking change is that the final `typeInfo` argument to `validate` has moved positions. However very few should be reliant on this experimental arg.

@dschafer

… definition Based on discussion with @dschafer Adds getDefaultValue() to TypeInfo so the default value at any position in an AST visit is known.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

SPEC/BUG: Ambiguity with null variable values and default values #1274

SPEC/BUG: Ambiguity with null variable values and default values #1274

Commits on Apr 18, 2018