graphql-tools
graphql-tools copied to clipboard
Aliasing not working if multiple stiched layers are used
Issue workflow progress
Progress of the issue based on the Contributor Workflow
- [x] 1. The issue provides a reproduction available on Github, Stackblitz or CodeSandbox
Make sure to fork this template and run
yarn generatein the terminal.Please make sure the GraphQL Tools package versions under
package.jsonmatches yours. - [ ] 2. A failing test has been provided
- [ ] 3. A local solution has been provided
- [ ] 4. A pull request is pending review
Describe the bug
We are experiencing an aliasing issue in a multilayer stitching setting. The issue is that once an alias is used within the query the aliasing is lost somewhere within the stiching process. I am fairly new to GraphQL and GraphQL Tools and could not narrow it down further. The reproduction is a the bare minimum required to trigger the issue.
To Reproduce Steps to reproduce the behavior:
- Go to https://codesandbox.io/s/5nfdct?file=/index.js
- Issue the following Query:
{
film(id: "ZmlsbXM6MQ==") {
id
x: title
planetConnection{
planets {
name
}
baz: newProp {
id
title
}
}
}
}
The query is only partially successful with the following output:
{
"errors": [
{
"message": "Cannot return null for non-nullable field FilmPlanetsConnection.newProp.",
"locations": [
{
"line": 9,
"column": 7
}
],
"path": [
"film",
"planetConnection",
"baz"
],
"extensions": {
"code": "INTERNAL_SERVER_ERROR",
"exception": {
"stacktrace": [
"Error: Cannot return null for non-nullable field FilmPlanetsConnection.newProp.",
" at completeValue (/Users/mairt/Downloads/apollo-tools-bug-repro-forked/node_modules/graphql/execution/execute.js:594:13)",
" at executeField (/Users/mairt/Downloads/apollo-tools-bug-repro-forked/node_modules/graphql/execution/execute.js:489:19)",
" at executeFields (/Users/mairt/Downloads/apollo-tools-bug-repro-forked/node_modules/graphql/execution/execute.js:413:20)",
" at completeObjectValue (/Users/mairt/Downloads/apollo-tools-bug-repro-forked/node_modules/graphql/execution/execute.js:914:10)",
" at completeValue (/Users/mairt/Downloads/apollo-tools-bug-repro-forked/node_modules/graphql/execution/execute.js:635:12)",
" at /Users/mairt/Downloads/apollo-tools-bug-repro-forked/node_modules/graphql/execution/execute.js:486:9",
" at processTicksAndRejections (node:internal/process/task_queues:96:5)",
" at async Promise.all (index 2)"
]
}
}
}
],
"data": {
"film": {
"id": "ZmlsbXM6MQ== id",
"x": "ZmlsbXM6MQ== film title",
"planetConnection": null
}
}
}
Expected behavior The query should have the following output:
{
"data": {
"film": {
"id": "ZmlsbXM6MQ== id",
"x": "ZmlsbXM6MQ== film title",
"planetConnection": {
"planets": [
{
"name": "0.41128816183728456 name"
}
],
"baz": {
"id": "ZmlsbXM6Mw== id",
"title": "ZmlsbXM6Mw== film title"
}
}
}
}
}
Additional context
The issue does not manifest itself if in the last layer the defaultMergedResolver is used (see comment in repro).
The issue is also no present when the alias on the newProp field is removed.
{
film(id: "ZmlsbXM6MQ==") {
id
x: title
planetConnection{
planets {
name
}
newProp {
id
title
}
}
}
}
I had a similar issue which may have the same root cause; hopefully this helps with troubleshooting. My scenario has only a single level of stitching, with a resolver that adds contextual information to the default result like so:
const resolvers = {
RemoteType: {
propertyThatForwardsParentInfo: {
resolve(parent, args, context, info) {
const defaultResult = defaultMergedResolver(parent, args, context, info);
return defaultResult ? { ...defaultResult, parentContext: parent.someProperty } : null;
}
}
}
};
The issue appears to be that whenever defaultMergedResolver would return an ExternalObject, any override to that resolver has to do the same, or the aliases can't be properly unrolled. I was able to work around the issue in the above example by using Object.assign to add my property to the result instead of returning a plain object.
We're having this same issue. Multi-level stitching fails by default, but if I invoke the type using ... on Typename in the query, that seems to wake it up for some reason