Skip to content

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

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

benjie
Copy link
Member

@benjie benjie commented Jul 10, 2025

:: 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.

@benjie benjie added the ✏️ Editorial PR is non-normative or does not influence implementation label Jul 10, 2025
Copy link

netlify bot commented Jul 10, 2025

Deploy Preview for graphql-spec-draft ready!

Name Link
🔨 Latest commit 4d6f01b
🔍 Latest deploy log https://app.netlify.com/projects/graphql-spec-draft/deploys/686ff7c46b446a0008ff9be3
😎 Deploy Preview https://deploy-preview-1183--graphql-spec-draft.netlify.app
📱 Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify project configuration.

@benjie benjie force-pushed the clarify-one-error-per-result-position branch from 599b654 to a3092d9 Compare July 10, 2025 13:11
@ddebrunner

This comment was marked as outdated.

@benjie

This comment was marked as outdated.

@benjie benjie force-pushed the clarify-one-error-per-result-position branch from a3092d9 to fc70008 Compare July 10, 2025 16:00
@benjie benjie changed the title Clarify error reporting for siblings of error propagation Fix "response position" definition; clarify sibling errors on propagation Jul 10, 2025
@benjie benjie force-pushed the clarify-one-error-per-result-position branch 2 times, most recently from e199ebb to 4d6f01b Compare July 10, 2025 17:26
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
✏️ Editorial PR is non-normative or does not influence implementation
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants