Skip to main content

Fix "response position" definition; clarify sibling errors on propagation

At a glance​

Timeline​

:: A response position is a uniquely identifiable position in the response data produced during execution. It is either a direct entry in the {resultMap} of a {ExecuteSelectionSet()}, or it is a position in a (potentially nested) List value. Each response position is uniquely identifiable via a response path.

The intention of response position is that it includes things that were elided by error propagation; e.g. if you query { a { b } } and b is non-null and throws, the result will be {a: null} but the error will have path ["a", "b"] indicating the a.b response position even though that position does not actually exist in the response.

(Also: ExecuteSelectionSet() doesn't exist any more.)

Commit 1: clarify definition of response position to include these omitted values.

If a response position resolves to {null} because of an execution error which has already been added to the {"errors"} list in the execution result, the {"errors"} list must not be further affected. That is, only one error should be added to the errors list per response position.

But the response position mentioned at the beginning of this paragraph is different to the response position from which the error originated; therefore "only one error should be added to the errors list per response position" is kind of moot. Actually what we mean here is that the response path of the error (i.e. the "path" entry in the error object) should be unique.

Commit 2: clarify it's the "path" of the error that matters, not the position that re-raised it

The use of the term "response position" is confusing, because that position might not actually exist in the response if it was omitted due to error propagation.

Commit 3: rename response position to execution position throughout.

All of this together clarifies what happens when an error occurs to a nullable sibling of a non-nullable field that triggers error propagation.