From 8efb84c46f2e526aee0673d7ebeea938e54e2cf8 Mon Sep 17 00:00:00 2001 From: Martin Bonnin Date: Wed, 2 Apr 2025 22:36:53 +0200 Subject: [PATCH 1/5] Exclude custom scalar literals from validation --- spec/Section 5 -- Validation.md | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/spec/Section 5 -- Validation.md b/spec/Section 5 -- Validation.md index 6cebd7310..bf0fccacc 100644 --- a/spec/Section 5 -- Validation.md +++ b/spec/Section 5 -- Validation.md @@ -1306,9 +1306,10 @@ fragment resourceFragment on Resource { - For each literal Input Value {value} in the document: - Let {type} be the type expected in the position {value} is found. - - {value} must be coercible to {type} (with the assumption that any - {variableUsage} nested within {value} will represent a runtime value valid - for usage in its position). + - If {type} is not a custom scalar type: + - {value} must be coercible to {type} (with the assumption that any + {variableUsage} nested within {value} will represent a runtime value valid + for usage in its position). **Explanatory Text** @@ -1324,6 +1325,11 @@ algorithm ensures runtime values for variables coerce correctly. Therefore, for the purposes of the "coercible" assertion in this validation rule, we can assume the runtime value of each {variableUsage} is valid for usage in its position. +Note: Custom scalar coercion rules are not always available when validating a +document and custom scalar literal values are excluded from this validation. If +a custom scalar literal value cannot be coerced, it will raise an execution +error. + The type expected in a position includes the type defined by the argument a value is provided for, the type defined by an input object field a value is provided for, and the type of a variable definition a default value is provided From f34e98bd1c3c9102f9fcb7fac6b09870d0e342a8 Mon Sep 17 00:00:00 2001 From: Martin Bonnin Date: Wed, 2 Apr 2025 22:06:33 +0200 Subject: [PATCH 2/5] Clarify that variables are always allowed when part of a custom scalar literal value Fixes #1011 --- spec/Section 5 -- Validation.md | 1 + 1 file changed, 1 insertion(+) diff --git a/spec/Section 5 -- Validation.md b/spec/Section 5 -- Validation.md index bf0fccacc..728502127 100644 --- a/spec/Section 5 -- Validation.md +++ b/spec/Section 5 -- Validation.md @@ -1890,6 +1890,7 @@ variable. IsVariableUsageAllowed(variableDefinition, variableUsage): +- If {variableUsage} is nested in a custom scalar literal value, return {true}. - Let {variableType} be the expected type of {variableDefinition}. - Let {locationType} be the expected type of the {Argument}, {ObjectField}, or {ListValue} entry where {variableUsage} is located. From bf42aa1df1cf006edcefba21d9d1581bac154bde Mon Sep 17 00:00:00 2001 From: Martin Bonnin Date: Thu, 3 Apr 2025 13:00:02 +0200 Subject: [PATCH 3/5] add note --- spec/Section 5 -- Validation.md | 16 +++++++++++++++- 1 file changed, 15 insertions(+), 1 deletion(-) diff --git a/spec/Section 5 -- Validation.md b/spec/Section 5 -- Validation.md index 728502127..897f8168c 100644 --- a/spec/Section 5 -- Validation.md +++ b/spec/Section 5 -- Validation.md @@ -1890,7 +1890,8 @@ variable. IsVariableUsageAllowed(variableDefinition, variableUsage): -- If {variableUsage} is nested in a custom scalar literal value, return {true}. +- If {variableUsage} is nested within a custom scalar literal value, return + {true}. - Let {variableType} be the expected type of {variableDefinition}. - Let {locationType} be the expected type of the {Argument}, {ObjectField}, or {ListValue} entry where {variableUsage} is located. @@ -1981,6 +1982,19 @@ query nonNullListToList($nonNullBooleanList: [Boolean]!) { } ``` +When using variables nested within custom scalars literals, the expected type is +unknown, and variable usages are always allowed. The actual value is coerced at +runtime using the custom scalar coercion rules. In the following case, the +`user` argument expects a `JSON` custom scalar, and it is valid for it to +reference variables: + +```graphql example +mutation updateUserName($name: String!) { + # This usage of the $name variable is valid + updateUser(user: { name: $name }) +} +``` + However, a nullable list cannot be passed to a non-null list: ```graphql counter-example From e324a001acb36a7c913b5ae85b97f985b2c01a18 Mon Sep 17 00:00:00 2001 From: Martin Bonnin Date: Thu, 17 Apr 2025 11:34:18 +0200 Subject: [PATCH 4/5] Update spec/Section 5 -- Validation.md --- spec/Section 5 -- Validation.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/spec/Section 5 -- Validation.md b/spec/Section 5 -- Validation.md index 897f8168c..f3c92734e 100644 --- a/spec/Section 5 -- Validation.md +++ b/spec/Section 5 -- Validation.md @@ -1326,9 +1326,9 @@ the purposes of the "coercible" assertion in this validation rule, we can assume the runtime value of each {variableUsage} is valid for usage in its position. Note: Custom scalar coercion rules are not always available when validating a -document and custom scalar literal values are excluded from this validation. If -a custom scalar literal value cannot be coerced, it will raise an execution -error. +document and custom scalar literal values are optional in this validation. If +a custom scalar literal value cannot be coerced, it will raise an error during +execution. The type expected in a position includes the type defined by the argument a value is provided for, the type defined by an input object field a value is From 07412165a7e489819f5ad5f2854af4a7d46abd29 Mon Sep 17 00:00:00 2001 From: Martin Bonnin Date: Thu, 17 Apr 2025 11:36:08 +0200 Subject: [PATCH 5/5] formatting --- spec/Section 5 -- Validation.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/spec/Section 5 -- Validation.md b/spec/Section 5 -- Validation.md index f3c92734e..5fca2b9e3 100644 --- a/spec/Section 5 -- Validation.md +++ b/spec/Section 5 -- Validation.md @@ -1326,8 +1326,8 @@ the purposes of the "coercible" assertion in this validation rule, we can assume the runtime value of each {variableUsage} is valid for usage in its position. Note: Custom scalar coercion rules are not always available when validating a -document and custom scalar literal values are optional in this validation. If -a custom scalar literal value cannot be coerced, it will raise an error during +document and custom scalar literal values are optional in this validation. If a +custom scalar literal value cannot be coerced, it will raise an error during execution. The type expected in a position includes the type defined by the argument a