From eee64e9437b56ad649cba3c4a561362e3b14799b Mon Sep 17 00:00:00 2001 From: Lee Byron Date: Tue, 21 Jun 2022 13:38:46 -0700 Subject: [PATCH 1/4] Editorial: Error Terminology Uses the definition syntax to set definitions for "field error" and "request error", and uses italic references in every formal normative location as well as the first reference in each prose. This also clarifies when we previously used a plural "field errors" that we actually mean "a list of field error" Include links to other sections as set up in #957 Co-authored-by: Roman Ivantsov --- spec/Section 3 -- Type System.md | 97 ++++++++++++++++---------------- spec/Section 5 -- Validation.md | 2 +- spec/Section 6 -- Execution.md | 49 ++++++++-------- spec/Section 7 -- Response.md | 32 ++++++----- 4 files changed, 94 insertions(+), 86 deletions(-) diff --git a/spec/Section 3 -- Type System.md b/spec/Section 3 -- Type System.md index 0d44913a6..7175d08be 100644 --- a/spec/Section 3 -- Type System.md +++ b/spec/Section 3 -- Type System.md @@ -300,8 +300,8 @@ A GraphQL schema may describe that a field represents a list of another type; the `List` type is provided for this reason, and wraps another type. Similarly, the `Non-Null` type wraps another type, and denotes that the -resulting value will never be {null} (and that a field error cannot result in a -{null} value). +resulting value will never be {null} (and that a _field error_ cannot result in +a {null} value). These two types are referred to as "wrapping types"; non-wrapping types are referred to as "named types". A wrapping type has an underlying named type, @@ -425,14 +425,14 @@ examples in their description. A GraphQL service, when preparing a field of a given scalar type, must uphold the contract the scalar type describes, either by coercing the value or -producing a [field error](#sec-Errors.Field-errors) if a value cannot be coerced -or if coercion may result in data loss. +producing a _field error_ if a value cannot be coerced or if coercion may result +in data loss. A GraphQL service may decide to allow coercing different internal types to the expected return type. For example when coercing a field of type {Int} a boolean {true} value may produce {1} or a string value {"123"} may be parsed as base-10 {123}. However if internal type coercion cannot be reasonably performed without -losing information, then it must raise a field error. +losing information, then it must raise a _field error_. Since this coercion behavior is not observable to clients of the GraphQL service, the precise rules of coercion are left to the implementation. The only @@ -450,8 +450,8 @@ information on the serialization of scalars in common JSON and other formats. If a GraphQL service expects a scalar type as input to an argument, coercion is observable and the rules must be well defined. If an input value does not match -a coercion rule, a [request error](#sec-Errors.Request-errors) must be raised -(input values are validated before execution begins). +a coercion rule, a _request error_ must be raised (input values are validated +before execution begins). GraphQL has different constant literals to represent integer and floating-point input values, and coercion rules may apply differently depending on which type @@ -477,14 +477,15 @@ Fields returning the type {Int} expect to encounter 32-bit integer internal values. GraphQL services may coerce non-integer internal values to integers when -reasonable without losing information, otherwise they must raise a field error. -Examples of this may include returning `1` for the floating-point number `1.0`, -or returning `123` for the string `"123"`. In scenarios where coercion may lose -data, raising a field error is more appropriate. For example, a floating-point -number `1.2` should raise a field error instead of being truncated to `1`. +reasonable without losing information, otherwise they must raise a _field +error_. Examples of this may include returning `1` for the floating-point number +`1.0`, or returning `123` for the string `"123"`. In scenarios where coercion +may lose data, raising a field error is more appropriate. For example, a +floating-point number `1.2` should raise a field error instead of being +truncated to `1`. If the integer internal value represents a value less than -231 or -greater than or equal to 231, a field error should be raised. +greater than or equal to 231, a _field error_ should be raised. **Input Coercion** @@ -492,7 +493,7 @@ When expected as an input type, only integer input values are accepted. All other input values, including strings with numeric content, must raise a request error indicating an incorrect type. If the integer input value represents a value less than -231 or greater than or equal to 231, a -request error should be raised. +_request error_ should be raised. Note: Numeric integer values larger than 32-bit should either use String or a custom-defined Scalar type, as not all platforms and transports support encoding @@ -511,22 +512,22 @@ Fields returning the type {Float} expect to encounter double-precision floating-point internal values. GraphQL services may coerce non-floating-point internal values to {Float} when -reasonable without losing information, otherwise they must raise a field error. -Examples of this may include returning `1.0` for the integer number `1`, or -`123.0` for the string `"123"`. +reasonable without losing information, otherwise they must raise a _field +error_. Examples of this may include returning `1.0` for the integer number `1`, +or `123.0` for the string `"123"`. Non-finite floating-point internal values ({NaN} and {Infinity}) cannot be -coerced to {Float} and must raise a field error. +coerced to {Float} and must raise a _field error_. **Input Coercion** When expected as an input type, both integer and float input values are accepted. Integer input values are coerced to Float by adding an empty fractional part, for example `1.0` for the integer input value `1`. All other -input values, including strings with numeric content, must raise a request error -indicating an incorrect type. If the input value otherwise represents a value -not representable by finite IEEE 754 (e.g. {NaN}, {Infinity}, or a value outside -the available precision), a request error must be raised. +input values, including strings with numeric content, must raise a _request +error_ indicating an incorrect type. If the input value otherwise represents a +value not representable by finite IEEE 754 (e.g. {NaN}, {Infinity}, or a value +outside the available precision), a _request error_ must be raised. ### String @@ -542,14 +543,14 @@ that representation must be used to serialize this type. Fields returning the type {String} expect to encounter Unicode string values. GraphQL services may coerce non-string raw values to {String} when reasonable -without losing information, otherwise they must raise a field error. Examples of -this may include returning the string `"true"` for a boolean true value, or the -string `"1"` for the integer `1`. +without losing information, otherwise they must raise a _field error_. Examples +of this may include returning the string `"true"` for a boolean true value, or +the string `"1"` for the integer `1`. **Input Coercion** When expected as an input type, only valid Unicode string input values are -accepted. All other input values must raise a request error indicating an +accepted. All other input values must raise a _request error_ indicating an incorrect type. ### Boolean @@ -563,13 +564,13 @@ representation of the integers `1` and `0`. Fields returning the type {Boolean} expect to encounter boolean internal values. GraphQL services may coerce non-boolean raw values to {Boolean} when reasonable -without losing information, otherwise they must raise a field error. Examples of -this may include returning `true` for non-zero numbers. +without losing information, otherwise they must raise a _field error_. Examples +of this may include returning `true` for non-zero numbers. **Input Coercion** When expected as an input type, only boolean input values are accepted. All -other input values must raise a request error indicating an incorrect type. +other input values must raise a _request error_ indicating an incorrect type. ### ID @@ -586,15 +587,15 @@ large 128-bit random numbers, to base64 encoded values, or string values of a format like [GUID](https://en.wikipedia.org/wiki/Globally_unique_identifier). GraphQL services should coerce as appropriate given the ID formats they expect. -When coercion is not possible they must raise a field error. +When coercion is not possible they must raise a _field error_. **Input Coercion** When expected as an input type, any string (such as `"4"`) or integer (such as `4` or `-4`) input value should be coerced to ID as appropriate for the ID formats a given GraphQL service expects. Any other input value, including float -input values (such as `4.0`), must raise a request error indicating an incorrect -type. +input values (such as `4.0`), must raise a _request error_ indicating an +incorrect type. ### Scalar Extensions @@ -1448,7 +1449,7 @@ enum Direction { **Result Coercion** GraphQL services must return one of the defined set of possible values. If a -reasonable coercion is not possible they must raise a field error. +reasonable coercion is not possible they must raise a _field error_. **Input Coercion** @@ -1584,9 +1585,9 @@ type of an Object or Interface field. **Input Coercion** The value for an input object should be an input object literal or an unordered -map supplied by a variable, otherwise a request error must be raised. In either -case, the input object literal or unordered map must not contain any entries -with names not defined by a field of this input object type, otherwise a +map supplied by a variable, otherwise a _request error_ must be raised. In +either case, the input object literal or unordered map must not contain any +entries with names not defined by a field of this input object type, otherwise a response error must be raised. The result of coercion is an unordered map with an entry for each field both @@ -1610,7 +1611,7 @@ is constructed with the following rules: - If a variable is provided for an input object field, the runtime value of that variable must be used. If the runtime value is {null} and the field type is - non-null, a field error must be raised. If no runtime value is provided, the + non-null, a _field error_ must be raised. If no runtime value is provided, the variable definition's default value should be used. If the variable definition does not provide a default value, the input object field definition's default value should be used. @@ -1698,13 +1699,14 @@ brackets like this: `pets: [Pet]`. Nesting lists is allowed: `matrix: [[Int]]`. GraphQL services must return an ordered list as the result of a list type. Each item in the list must be the result of a result coercion of the item type. If a -reasonable coercion is not possible it must raise a field error. In particular, -if a non-list is returned, the coercion should fail, as this indicates a -mismatch in expectations between the type system and the implementation. +reasonable coercion is not possible it must raise a _field error_. In +particular, if a non-list is returned, the coercion should fail, as this +indicates a mismatch in expectations between the type system and the +implementation. If a list's item type is nullable, then errors occurring during preparation or coercion of an individual item in the list must result in a the value {null} at -that position in the list along with a field error added to the response. If a +that position in the list along with a _field error_ added to the response. If a list's item type is non-null, a field error occurring at an individual item in the list must result in a field error for the entire list. @@ -1764,19 +1766,20 @@ always optional and non-null types are always required. In all of the above result coercions, {null} was considered a valid value. To coerce the result of a Non-Null type, the coercion of the wrapped type should be performed. If that result was not {null}, then the result of coercing the -Non-Null type is that result. If that result was {null}, then a field error must -be raised. +Non-Null type is that result. If that result was {null}, then a _field error_ +must be raised. -Note: When a field error is raised on a non-null value, the error propagates to -the parent field. For more information on this process, see "Errors and -Non-Nullability" within the Execution section. +Note: When a _field error_ is raised on a non-null value, the error propagates +to the parent field. For more information on this process, see +[Errors and Non-Null Fields](#sec-Executing-Selection-Sets.Errors-and-Non-Null-Fields) +within the Execution section. **Input Coercion** If an argument or input-object field of a Non-Null type is not provided, is provided with the literal value {null}, or is provided with a variable that was either not provided a value at runtime, or was provided the value {null}, then a -request error must be raised. +_request error_ must be raised. If the value provided to the Non-Null type is provided with a literal value other than {null}, or a Non-Null variable value, it is coerced using the input diff --git a/spec/Section 5 -- Validation.md b/spec/Section 5 -- Validation.md index 5d6fcb0e9..aa4c46996 100644 --- a/spec/Section 5 -- Validation.md +++ b/spec/Section 5 -- Validation.md @@ -2005,4 +2005,4 @@ query booleanArgQueryWithDefault($booleanArg: Boolean = true) { ``` Note: The value {null} could still be provided to such a variable at runtime. A -non-null argument must raise a field error if provided a {null} value. +non-null argument must raise a _field error_ if provided a {null} value. diff --git a/spec/Section 6 -- Execution.md b/spec/Section 6 -- Execution.md index c02f5f47e..61d812743 100644 --- a/spec/Section 6 -- Execution.md +++ b/spec/Section 6 -- Execution.md @@ -48,10 +48,10 @@ GetOperation(document, operationName): - If {operationName} is {null}: - If {document} contains exactly one operation. - Return the Operation contained in the {document}. - - Otherwise raise a request error requiring {operationName}. + - Otherwise raise a _request error_ requiring {operationName}. - Otherwise: - Let {operation} be the Operation named {operationName} in {document}. - - If {operation} was not found, raise a request error. + - If {operation} was not found, raise a _request error_. - Return {operation}. ### Validating Requests @@ -75,8 +75,8 @@ result to avoid validating the same request again in the future. If the operation has defined any variables, then the values for those variables need to be coerced using the input coercion rules of variable's declared type. -If a request error is encountered during input coercion of variable values, then -the operation fails without execution. +If a _request error_ is encountered during input coercion of variable values, +then the operation fails without execution. CoerceVariableValues(schema, operation, variableValues): @@ -95,14 +95,14 @@ CoerceVariableValues(schema, operation, variableValues): - Add an entry to {coercedValues} named {variableName} with the value {defaultValue}. - Otherwise if {variableType} is a Non-Nullable type, and either {hasValue} is - not {true} or {value} is {null}, raise a request error. + not {true} or {value} is {null}, raise a _request error_. - Otherwise if {hasValue} is true: - If {value} is {null}: - Add an entry to {coercedValues} named {variableName} with the value {null}. - Otherwise: - If {value} cannot be coerced according to the input coercion rules of - {variableType}, raise a request error. + {variableType}, raise a _request error_. - Let {coercedValue} be the result of coercing {value} according to the input coercion rules of {variableType}. - Add an entry to {coercedValues} named {variableName} with the value @@ -134,7 +134,8 @@ ExecuteQuery(query, schema, variableValues, initialValue): - Let {data} be the result of running {ExecuteSelectionSet(selectionSet, queryType, initialValue, variableValues)} _normally_ (allowing parallelization). -- Let {errors} be any _field errors_ produced while executing the selection set. +- Let {errors} be the list of all _field error_ raised while executing the + selection set. - Return an unordered map containing {data} and {errors}. ### Mutation @@ -154,7 +155,8 @@ ExecuteMutation(mutation, schema, variableValues, initialValue): - Let {selectionSet} be the top level Selection Set in {mutation}. - Let {data} be the result of running {ExecuteSelectionSet(selectionSet, mutationType, initialValue, variableValues)} _serially_. -- Let {errors} be any _field errors_ produced while executing the selection set. +- Let {errors} be the list of all _field error_ raised while executing the + selection set. - Return an unordered map containing {data} and {errors}. ### Subscription @@ -256,7 +258,7 @@ CreateSourceEventStream(subscription, schema, variableValues, initialValue): - Let {selectionSet} be the top level Selection Set in {subscription}. - Let {groupedFieldSet} be the result of {CollectFields(subscriptionType, selectionSet, variableValues)}. -- If {groupedFieldSet} does not have exactly one entry, raise a request error. +- If {groupedFieldSet} does not have exactly one entry, raise a _request error_. - Let {fields} be the value of the first entry in {groupedFieldSet}. - Let {fieldName} be the name of the first entry in {fields}. Note: This value is unaffected if an alias is used. @@ -302,7 +304,8 @@ ExecuteSubscriptionEvent(subscription, schema, variableValues, initialValue): - Let {data} be the result of running {ExecuteSelectionSet(selectionSet, subscriptionType, initialValue, variableValues)} _normally_ (allowing parallelization). -- Let {errors} be any _field errors_ produced while executing the selection set. +- Let {errors} be the list of all _field error_ raised while executing the + selection set. - Return an unordered map containing {data} and {errors}. Note: The {ExecuteSubscriptionEvent()} algorithm is intentionally similar to @@ -351,8 +354,8 @@ is explained in greater detail in the Field Collection section below. **Errors and Non-Null Fields** If during {ExecuteSelectionSet()} a field with a non-null {fieldType} raises a -field error then that error must propagate to this entire selection set, either -resolving to {null} if allowed or further propagated to a parent field. +_field error_ then that error must propagate to this entire selection set, +either resolving to {null} if allowed or further propagated to a parent field. If this occurs, any sibling fields which have not yet executed or have not yet yielded a value may be cancelled to avoid unnecessary work. @@ -616,7 +619,7 @@ CoerceArgumentValues(objectType, field, variableValues): - Add an entry to {coercedValues} named {argumentName} with the value {defaultValue}. - Otherwise if {argumentType} is a Non-Nullable type, and either {hasValue} is - not {true} or {value} is {null}, raise a field error. + not {true} or {value} is {null}, raise a _field error_. - Otherwise if {hasValue} is true: - If {value} is {null}: - Add an entry to {coercedValues} named {argumentName} with the value @@ -626,7 +629,7 @@ CoerceArgumentValues(objectType, field, variableValues): {value}. - Otherwise: - If {value} cannot be coerced according to the input coercion rules of - {argumentType}, raise a field error. + {argumentType}, raise a _field error_. - Let {coercedValue} be the result of coercing {value} according to the input coercion rules of {argumentType}. - Add an entry to {coercedValues} named {argumentName} with the value @@ -672,12 +675,12 @@ CompleteValue(fieldType, fields, result, variableValues): - Let {innerType} be the inner type of {fieldType}. - Let {completedResult} be the result of calling {CompleteValue(innerType, fields, result, variableValues)}. - - If {completedResult} is {null}, raise a field error. + - If {completedResult} is {null}, raise a _field error_. - Return {completedResult}. - If {result} is {null} (or another internal value similar to {null} such as {undefined}), return {null}. - If {fieldType} is a List type: - - If {result} is not a collection of values, raise a field error. + - If {result} is not a collection of values, raise a _field error_. - Let {innerType} be the inner type of {fieldType}. - Return a list where each list item is the result of calling {CompleteValue(innerType, fields, resultItem, variableValues)}, where @@ -712,7 +715,7 @@ CoerceResult(leafType, value): - Return the result of calling the internal method provided by the type system for determining the "result coercion" of {leafType} given the value {value}. This internal method must return a valid value for the type and not {null}. - Otherwise throw a field error. + Otherwise raise a _field error_. Note: If a field resolver returns {null} then it is handled within {CompleteValue()} before {CoerceResult()} is called. Therefore both the input @@ -769,13 +772,13 @@ MergeSelectionSets(fields): ### Handling Field Errors -["Field errors"](#sec-Errors.Field-errors) are raised from a particular field -during value resolution or coercion. While these errors should be reported in -the response, they are "handled" by producing a partial response. +A _field error_ is an error raised from a particular field during value +resolution or coercion. While these errors should be reported in the response, +they are "handled" by producing a partial response. -Note: This is distinct from ["request errors"](#sec-Errors.Request-errors) which -are raised before execution begins. If a request error is encountered, execution -does not begin and no data is returned in the response. +Note: This is distinct from a _request error_ which is raised before execution +begins. If a request error is encountered, execution does not begin and no data +is returned in the response. If a field error is raised while resolving a field, it is handled as though the field returned {null}, and the error must be added to the {"errors"} list in the diff --git a/spec/Section 7 -- Response.md b/spec/Section 7 -- Response.md index 2e58276ab..018c99198 100644 --- a/spec/Section 7 -- Response.md +++ b/spec/Section 7 -- Response.md @@ -4,8 +4,9 @@ When a GraphQL service receives a _request_, it must return a well-formed response. The service's response describes the result of executing the requested operation if successful, and describes any errors raised during the request. -A response may contain both a partial response as well as any field errors in -the case that a field error was raised on a field and was replaced with {null}. +A response may contain both a partial response as well as a list of all _field +error_ in the case that any field error was raised on a field and was replaced +with {null}. ## Response Format @@ -60,33 +61,34 @@ response must not be empty. It must contain at least one error. The errors it contains should indicate why no data was able to be returned. If the `data` entry in the response is present (including if it is the value -{null}), the `errors` entry in the response may contain any field errors that -were raised during execution. If field errors were raised during execution, it -should contain those errors. +{null}), the `errors` entry in the response may contain a list of all _field +error_ that were raised during execution. If any _field error_ was raised during +execution, it should contain the `errors` entry. **Request errors** -Request errors are raised before execution begins. This may occur due to a parse -grammar or validation error in the requested document, an inability to determine -which operation to execute, or invalid input values for variables. +:: A _request error_ is an error raised during a _request_ but before execution +begins. This may occur due to a parse grammar or validation error in the +_Document_, an inability to determine which operation to execute, or invalid +input values for variables. -Request errors are typically the fault of the requesting client. +A request error is typically the fault of the requesting client. If a request error is raised, execution does not begin and the `data` entry in the response must not be present. The `errors` entry must include the error. **Field errors** -Field errors are raised during execution from a particular field. This may occur -due to an internal error during value resolution or failure to coerce the -resulting value. +:: A _field error_ is raised during the execution of a particular field. This +may occur due to an internal error during value resolution or failure to coerce +the resulting value. -Field errors are typically the fault of GraphQL service. +A field error is typically the fault of a GraphQL service. If a field error is raised, execution attempts to continue and a partial result is produced (see [Handling Field Errors](#sec-Handling-Field-Errors)). The -`data` entry in the response must be present. The `errors` entry should include -all raised field errors. +`data` entry in the response must be present. The `errors` entry should be a +list of all raised field errors. **Error result format** From 9e70c721171fdc11cffbc316b6168cf893b0408c Mon Sep 17 00:00:00 2001 From: Lee Byron Date: Wed, 22 Jun 2022 13:22:01 -0700 Subject: [PATCH 2/4] Review feedback plus clarification of error definition and should/must --- spec/Section 6 -- Execution.md | 5 ++-- spec/Section 7 -- Response.md | 42 ++++++++++++++++++---------------- 2 files changed, 24 insertions(+), 23 deletions(-) diff --git a/spec/Section 6 -- Execution.md b/spec/Section 6 -- Execution.md index 61d812743..28862ea89 100644 --- a/spec/Section 6 -- Execution.md +++ b/spec/Section 6 -- Execution.md @@ -776,9 +776,8 @@ A _field error_ is an error raised from a particular field during value resolution or coercion. While these errors should be reported in the response, they are "handled" by producing a partial response. -Note: This is distinct from a _request error_ which is raised before execution -begins. If a request error is encountered, execution does not begin and no data -is returned in the response. +Note: This is distinct from a _request error_ which results in a response with +no data. If a field error is raised while resolving a field, it is handled as though the field returned {null}, and the error must be added to the {"errors"} list in the diff --git a/spec/Section 7 -- Response.md b/spec/Section 7 -- Response.md index 018c99198..c60a96d38 100644 --- a/spec/Section 7 -- Response.md +++ b/spec/Section 7 -- Response.md @@ -50,45 +50,47 @@ If an error was raised during the execution that prevented a valid response, the ### Errors -The `errors` entry in the response is a non-empty list of errors, where each -error is a map. +The `errors` entry in the response is a non-empty list of errors raised during +the _request_, where each error is a map of data described by the error result +format below. -If no errors were raised during the request, the `errors` entry should not be +If present, the `errors` entry in the response must contain at least one error. +If no errors were raised during the request, the `errors` entry must not be present in the result. -If the `data` entry in the response is not present, the `errors` entry in the -response must not be empty. It must contain at least one error. The errors it -contains should indicate why no data was able to be returned. +If the `data` entry in the response is not present, the `errors` entry must be +present. It must contain at least one _request error_ indicating why no data was +able to be returned. If the `data` entry in the response is present (including if it is the value -{null}), the `errors` entry in the response may contain a list of all _field -error_ that were raised during execution. If any _field error_ was raised during -execution, it should contain the `errors` entry. +{null}), the `errors` entry must also be present if a _field error_ was raised +during execution. **Request errors** -:: A _request error_ is an error raised during a _request_ but before execution -begins. This may occur due to a parse grammar or validation error in the -_Document_, an inability to determine which operation to execute, or invalid -input values for variables. +:: A _request error_ is an error raised during a _request_ which results in no +response data. Typically raised before execution begins, a request error may +occur due to a parse grammar or validation error in the _Document_, an inability +to determine which operation to execute, or invalid input values for variables. A request error is typically the fault of the requesting client. -If a request error is raised, execution does not begin and the `data` entry in -the response must not be present. The `errors` entry must include the error. +If a request error is raised, the `data` entry in the response must not be +present. If a request error is encountered before execution, execution should +not begin. The `errors` entry must include the error. **Field errors** -:: A _field error_ is raised during the execution of a particular field. This -may occur due to an internal error during value resolution or failure to coerce -the resulting value. +:: A _field error_ is an error raised during the execution of a particular field +which results in partial response data. This may occur due to an internal error +during value resolution or failure to coerce the resulting value. A field error is typically the fault of a GraphQL service. If a field error is raised, execution attempts to continue and a partial result is produced (see [Handling Field Errors](#sec-Handling-Field-Errors)). The -`data` entry in the response must be present. The `errors` entry should be a -list of all raised field errors. +`data` entry in the response must be present. The `errors` entry should include +this error. **Error result format** From e503ac4bb088aa5fb931a2b189f9b0310cd672c6 Mon Sep 17 00:00:00 2001 From: Lee Byron Date: Thu, 23 Jun 2022 10:53:45 -0700 Subject: [PATCH 3/4] Review feedback Co-authored-by: Benjie Gillam --- spec/Section 7 -- Response.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/spec/Section 7 -- Response.md b/spec/Section 7 -- Response.md index c60a96d38..ec3ef6a03 100644 --- a/spec/Section 7 -- Response.md +++ b/spec/Section 7 -- Response.md @@ -63,8 +63,8 @@ present. It must contain at least one _request error_ indicating why no data was able to be returned. If the `data` entry in the response is present (including if it is the value -{null}), the `errors` entry must also be present if a _field error_ was raised -during execution. +{null}), the `errors` entry must be present if and only if one or more _field +error_ was raised during execution. **Request errors** @@ -76,8 +76,8 @@ to determine which operation to execute, or invalid input values for variables. A request error is typically the fault of the requesting client. If a request error is raised, the `data` entry in the response must not be -present. If a request error is encountered before execution, execution should -not begin. The `errors` entry must include the error. +present, the `errors` entry must include the error, and request execution should +be halted. **Field errors** From 69cd302bbcb75ca38d789aa38baacf499e2cd152 Mon Sep 17 00:00:00 2001 From: Lee Byron Date: Thu, 23 Jun 2022 16:24:18 -0700 Subject: [PATCH 4/4] Fix one resolvable pluralization --- spec/Section 7 -- Response.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/spec/Section 7 -- Response.md b/spec/Section 7 -- Response.md index ec3ef6a03..6d0aef511 100644 --- a/spec/Section 7 -- Response.md +++ b/spec/Section 7 -- Response.md @@ -4,9 +4,9 @@ When a GraphQL service receives a _request_, it must return a well-formed response. The service's response describes the result of executing the requested operation if successful, and describes any errors raised during the request. -A response may contain both a partial response as well as a list of all _field -error_ in the case that any field error was raised on a field and was replaced -with {null}. +A response may contain both a partial response as well as a list of errors in +the case that any _field error_ was raised on a field and was replaced with +{null}. ## Response Format