-
-
Notifications
You must be signed in to change notification settings - Fork 824
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
mergeSchemas does not report correct NonNullable field errors #1047
Labels
Comments
@yaacovCR It seems this bug is not fixed when I run the @mikebm's example with the new
|
yaacovCR
added a commit
that referenced
this issue
Jun 16, 2020
yaacovCR
added a commit
that referenced
this issue
Jun 17, 2020
yaacovCR
added a commit
that referenced
this issue
Jun 19, 2020
fix includes changes to error proxying = no longer relying on graphql-js to automatically set path of stitched error = now relying on graphql-js not modifying path of resolver-returned error even if references a path different from resolver = streamlines object error annotations to represent a map of errors by the field name = introduces depth property for proxied results that must be updated during proxied result traversal for properly searching the error arrays = requires updating of advanced wrapping/hoisting resolvers
This was referenced Jul 2, 2020
Closed
yaacovCR
added a commit
that referenced
this issue
Aug 3, 2020
This is not the optimal way to address #1047 but is the most backwards compatible.
yaacovCR
added a commit
that referenced
this issue
Aug 23, 2020
This is not the optimal way to address #1047 but is the most backwards compatible.
yaacovCR
added a commit
that referenced
this issue
Aug 23, 2020
This is not the optimal way to address #1047 but is the most backwards compatible.
yaacovCR
added a commit
that referenced
this issue
Aug 23, 2020
This is not the optimal way to address #1047 but is the most backwards compatible.
Merged
yaacovCR
added a commit
that referenced
this issue
Aug 24, 2020
This is not the optimal way to address #1047 but is the most backwards compatible.
yaacovCR
added a commit
that referenced
this issue
Aug 25, 2020
This is not the optimal way to address #1047 but is the most backwards compatible.
yaacovCR
added a commit
that referenced
this issue
Aug 31, 2020
This is not the optimal way to address #1047 but is the most backwards compatible.
yaacovCR
added a commit
that referenced
this issue
Aug 31, 2020
This is not the optimal way to address #1047 but is the most backwards compatible.
yaacovCR
added a commit
that referenced
this issue
Sep 2, 2020
This is not the optimal way to address #1047 but is the most backwards compatible.
yaacovCR
added a commit
that referenced
this issue
Sep 4, 2020
This is not the optimal way to address #1047 but is the most backwards compatible.
yaacovCR
added a commit
that referenced
this issue
Sep 13, 2020
This is not the optimal way to address #1047 but is the most backwards compatible.
yaacovCR
added a commit
that referenced
this issue
Sep 21, 2020
This is not the optimal way to address #1047 but is the most backwards compatible.
yaacovCR
added a commit
that referenced
this issue
Sep 21, 2020
This is not the optimal way to address #1047 but is the most backwards compatible.
yaacovCR
added a commit
that referenced
this issue
Sep 21, 2020
This is not the optimal way to address #1047 but is the most backwards compatible.
yaacovCR
added a commit
that referenced
this issue
Sep 21, 2020
This is not the optimal way to address #1047 but is the most backwards compatible.
yaacovCR
added a commit
that referenced
this issue
Sep 30, 2020
This is not the optimal way to address #1047 but is the most backwards compatible.
yaacovCR
added a commit
that referenced
this issue
Oct 1, 2020
This is not the optimal way to address #1047 but is the most backwards compatible.
yaacovCR
added a commit
that referenced
this issue
Oct 6, 2020
This is not the optimal way to address #1047 but is the most backwards compatible.
yaacovCR
added a commit
that referenced
this issue
Oct 23, 2020
This is not the optimal way to address #1047 but is the most backwards compatible.
Fixed in v7 |
# for free
to join this conversation on GitHub.
Already have an account?
# to comment
When calling a resolver that returns an item that contains a list, and that list type has a NonNullable field, yet the data getting sent back is null, then the wrong error is reported.
Below is a working example. The error should be reporting URL, but it is reporting quantity instead. It apparently reports the first field no matter what is is.
We use mergeSchemas a lot and this error is pretty critical as it causes developers to spend debugging time in the wrong area of the code base.
The text was updated successfully, but these errors were encountered: