-
-
Notifications
You must be signed in to change notification settings - Fork 831
Description
Describe the bug
Using transforms with stitched schemas seems to skip adding the selectionSet
after the first nesting, e.g. using terminology from the documentation examples user => posts
works but user => posts => user
(contrived I know) skips adding the selectionSet
which results in an error. There's a few issues from v5 and v7 that seem similar to this, but they don't seem transforms-related.
To Reproduce
Repro repo here: https://github.com/CygnusRoboticus/double-stitch-repro. I started building something resembling my use-case with multiple backing transformed GQL services, but found that the example from the docs here exhibits the same problem and went with that instead. Removing the transforms corrects this issue and allows the stitched schemas to select the nested resolvers indefinitely.
EDIT: To clarify and help make this a little more searchable
# with transforms
query {
userById(id: 1) {
posts {
# manually selecting this avoids the error
# userId
user {
id
}
}
}
}
yields
{
"errors": [
{
"message": "Cannot return null for non-nullable field User.posts.",
"path": [
"userById",
"posts"
]
// additional properties omitted for brevity
}
],
"data": {
"userById": null
}
}
Expected behavior
I expect to be able to execute stitched resolvers from transformed schemas without having to manually select the values indicated in their selectionSet
configuration.
Environment:
- OS: Linux
- NodeJS: 14.18.0
@graphql-tools/delegate
: 8.4.3@graphql-tools/mock
: 8.5.1@graphql-tools/stitch
: 8.4.3@graphql-tools/utils
: 8.6.1@graphql-tools/wrap
: 8.3.3
Additional context
The failure above is present in the docs, but my actual use-case is fairly convoluted. I'm actually seeing this issue with one transformed schema being stitched into another transformed schema. I also recently did an upgrade from v6, but again the failure mode above is from the docs so I am unsure if that is related.