Skip to content

Introduce criteria G - error propagation boundaries not impacted #1654

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.

Sign up for GitHub

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

Merged
merged 1 commit into from
Feb 17, 2025
Merged

Introduce criteria G - error propagation boundaries not impacted #1654

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
22 changes: 22 additions & 0 deletions rfcs/SemanticNullability.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -277,6 +277,20 @@ not cause confusion.

Criteria score: 🥇

## 🎯 G. Error propagation boundaries should not change in existing executable documents

An expansion of B, this states that the proposal will not change where errors
propagate to when error propagation is enabled (i.e. existing documents will
still keep errors local to the same positions that they did when they were
published), allowing for the "partial success" feature of GraphQL to continue to
shine and not compromising the resiliency of legacy deployed app versions.

| [1][solution-1] | [2][solution-2] | [3][solution-3] | [4][solution-4] |
| --------------- | --------------- | --------------- | --------------- |
| ✅ | ✅ | ✅ | ✅ |

Criteria score: 🥇

<!--

Template for new items:
Expand Down Expand Up @@ -357,6 +371,8 @@ have been discussed the choice of symbol comes down mostly to aesthetics.
- ✅ Same syntax.
- [F][criteria-f]
- ✅ Same syntax.
- [G][criteria-g]
- ✅ Error capture positions unchanged when error propagation enabled

## 💡 2. "Strict Semantic Nullability"

Expand Down Expand Up @@ -394,6 +410,8 @@ symbol) to indicate that a position may semantically be null.
- ✅ The same syntax is used on input and output.
- [F][criteria-f]
- ✅ There is no alternative syntax.
- [G][criteria-g]
- ✅ Error capture positions unchanged when error propagation enabled

## 💡 3. New "Semantic Non-Null" type, usurping `!` syntax

Expand Down Expand Up @@ -454,6 +472,8 @@ day-to-day work.
non-nullable in both modes. Only the SDL ever uses `Int!!` and it still
means non-null, just with the additional "kills parent on exception"
behavior.
- [G][criteria-g]
- ✅ Error capture positions unchanged when error propagation enabled

## 💡 4. New "Semantic Non-Null" type, with `?` used for nullable types

Expand Down Expand Up @@ -489,3 +509,5 @@ directive is present, and a `?` symbol is used to indicate a nullable position.
- [F][criteria-f]
- 🚫 `Int` being nullable in one mode and non-nullable in the other mode is
unexpected and will likely lead to confusion.
- [G][criteria-g]
- ✅ Error capture positions unchanged when error propagation enabled