You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
[ ] Regression
[ ] Bug report
[x] Feature request
[ ] Documentation issue or request
[ ] Support request => Please do not submit support request here, instead post your question on Stack Overflow.
Current behavior
I'm using schema stitching, and when the downstream services update their schemas, the gateway (the nestjs service) doesn't notice the changes.
This is not a problem of nestjs/graphql, this is discussed in ardatan/graphql-tools#791 and apollographql/apollo-server#1275.
Expected behavior
To do the workaround, we need access to the apollo-server. I couldn't find any reference in the doc.
Minimal reproduction of the problem with instructions
A -> B
\ -> C
Change C's schema, restart C and do a query involving that change to A.
What is the motivation / use case for changing the behavior?
If C changes its schema, only restarting A makes the stitching happen again.
The text was updated successfully, but these errors were encountered:
I'm submitting a...
Current behavior
I'm using schema stitching, and when the downstream services update their schemas, the gateway (the nestjs service) doesn't notice the changes.
This is not a problem of nestjs/graphql, this is discussed in ardatan/graphql-tools#791 and apollographql/apollo-server#1275.
Expected behavior
To do the workaround, we need access to the apollo-server. I couldn't find any reference in the doc.
Minimal reproduction of the problem with instructions
A -> B
\ -> C
Change C's schema, restart C and do a query involving that change to A.
What is the motivation / use case for changing the behavior?
If C changes its schema, only restarting A makes the stitching happen again.
The text was updated successfully, but these errors were encountered: