Open xddq opened 2 years ago
Thanks for submitting this!!!
Are you able to post what query hits the remote schema?
Hey @yaacovCR , thanks for the fast response.
I did add query logging and the logging results into reproduction repo
The copy pasted QueryLog.md file:
query {articles {title {
... on TitleOne {text}
... on TitleTwo {renamedText: text}
}}}
remote-1 query: {
articles {
title {
... on TitleOne {
text
}
... on TitleTwo {
renamedText: text
}
}
}
}
remote-1 variables: {}
query {articles {title {
... on TitleOne {text}
... on TitleTwo {renamedText: text}
}}}
remote-1 query: {
articles {
title {
... on TitleOne {
text
}
... on TitleTwo {
renamedText: text
}
__typename
__typename
}
}
}
remote-1 variables: {}
stitched query: {
articles {
title {
... on TitleOne {
text
}
... on TitleTwo {
renamedText: text
}
}
}
}
stitched variables: {}
i tried to reproduce this with additional test and could not get it to fail.
perhaps the problem is the subschema implementation being used -- i am not familiar with it and used a local schema.
The queries look fine what about the remote response?
Mhhh, that's strange. I mean you did use subschemas as well here
I am currently trying to figure out how to log the response from the remote-1 server. Will post it once I figured it out.
Do you see any issue with the reproduction repo?
Log for the request-response cycle. Starting from stitched and starting from non-stitched.
query {
articles {
title {
... on TitleOne {
text
}
... on TitleTwo {
renamedText: text
}
}
}
}
[stitched] stitched request: {
[stitched] articles {
[stitched] title {
[stitched] ... on TitleOne {
[stitched] text
[stitched] }
[stitched] ... on TitleTwo {
[stitched] renamedText: text
[stitched] }
[stitched] }
[stitched] }
[stitched] }
[stitched]
[stitched] stitched variables: {}
[remote-*1] remote-1 request: {
[remote-*1] articles {
[remote-*1] title {
[remote-*1] ... on TitleOne {
[remote-*1] text
[remote-*1] }
[remote-*1] ... on TitleTwo {
[remote-*1] renamedText: text
[remote-*1] }
[remote-*1] __typename
[remote-*1] __typename
[remote-*1] }
[remote-*1] }
[remote-*1] }
[remote-*1] remote-1 variables: {}
[remote-*1] remote-1 response: {"articles":[{"title":{"text":"hello world","__typename":"TitleOne"}},{"title":{"renamedText":1,"__typename":"TitleTwo"}},{"title":{"renamedText":2,"__typename":"TitleTwo"}},{"title":{"text":"bye","__typename":"TitleOne"}}]}
[stitched] stitched response: {"articles":[{"title":{"text":"hello world"}},{"title":{"renamedText":null}},{"title":{"renamedText":null}},{"title":{"text":"bye"}}]}
[remote-*1] remote-1 request: {
[remote-*1] articles {
[remote-*1] title {
[remote-*1] ... on TitleOne {
[remote-*1] text
[remote-*1] }
[remote-*1] ... on TitleTwo {
[remote-*1] renamedText: text
[remote-*1] }
[remote-*1] }
[remote-*1] }
[remote-*1] }
[remote-*1]
[remote-*1] remote-1 variables: {}
[remote-*1] remote-1 response: {"articles":[{"title":{"text":"hello world"}},{"title":{"renamedText":1}},{"title":{"renamedText":2}},{"title":{"text":"bye"}}]}
Mhhh, that's strange. I mean you did use subschemas as well here
I used local subschemas, i mean, not local schemas. so the executor is the default executor not whatever you set up.
Do you see any issue with the reproduction repo?
Not from the brief glance, but I just looked at it enough to make a minimal reproduction. We will know more when you get the response from the remote subschema to show up.
In theory, if it can't be reproduced with local schemas, it's not a bug in stitching, it's a bug in the executor you are using => but that's just in theory. If you find anything I can fix, I would be very happy.
Okay so actually all that was needed was to add an executor to the subschema config. I am not yet sure how the executor works and why it is needed (since it worked without specifying one, besides the aliases on union types issue?)
I did upload the "corrected" version in the repro repo. I am not sure if this is still worth while to take a look into it for you.
Thanks a LOT for your time and your quick responses!
@xddq @yaacovCR I'm not adding anything here but just trying to label it correctly. So we couldn't yet reproduce it with a failing test but we do have a reproduction on a repo right?
@Urigo We have a reproduction repo, yes.
But I am not sure whether this is worth to get into since I did NOT specify an exectuor for my stitched schema while the documentation clearly states that an executor is needed. here, cited 2022-04-22-20:00:00
The only real bug (in my opinion) is that it did work without me ever specifiying an executor. It only failed while trying to rename attributes inside a union type.
I think it should error out when trying to create a subschema without specifying an executor, if one is required.
Issue workflow progress
Progress of the issue based on the Contributor Workflow
Describe the bug
To Reproduce Steps to reproduce the behavior:
npm i && npm run start
Expected behavior
{ "data": { "articles": [ { "title": { "text": "hello world" } }, { "title": { "renamedText": null } }, { "title": { "renamedText": null } }, { "title": { "text": "bye" } } ] } }