Open tmair opened 2 years ago
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
Issue workflow progress
Progress of the issue based on the Contributor Workflow
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:
The query is only partially successful with the following output:
Expected behavior The query should have the following output:
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 thenewProp
field is removed.