New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
stitchSchemas and schema delegation lose(doesn't forward) operatioName #2884
Comments
Thank you for reporting this issue @Aliaksei-Martsinkevich ! I'm not adding a lot here but just labeling it according to our new Contribution Guide and issue flow. It seems already got into Now in order to advance to Would be great if someone could help progress the issues through the stages. Thank you and sorry that this comment is not a complete solution (yet). |
#1924 (comment) Note that I think in the next major release we should go back to the old behavior of automatically forwarding the operationName and it can be overridden if necessary using the same type of workaround. In theory, @ardatan we could even release it as a bug fix, although it is breaking, I doubt anybody is actually relying on the operationName not being identical -- my argument WAS that in theory someone might be relying on just the operationName for query caching, but I have not yet seen anybody in the wild actually doing that. Or, we could just wait until the next major version, which I imagine will be with the next release of graphql-js? |
@yaacovCR we can do that for sure but what would happen if send multiple queries to the same source within the same operation? |
I guess that was my original concern, but even if identical, I guess adds helpful info as to ultimate source in Client, people don’t seem to care, and current behavior of dropping by default while technically more correct, seems to be unhelpful. I am on the fence about it, I think I should defer to you or anybody with more production experience actually using operation name |
Moving the comment from #4293 to here:
Even if we have multiple queries to same source to the same operation I think we should still forward the operation name as it was provided by the client. This is essentially what you are doing already, although you have chosen undefined as the common operation name instead of what the client provided.
I think this comment by @yaacovCR is on point. IDK if I agree that it is technically more correct, but I will trust you on that. But both from client perspective and from remote schema server perspective it is way more useful to have an operation name than to have compassion and understanding for what is "technically correct" 🧑🔬 The client can worry about splitting the operation up if necessary. |
Updated code sandbox with workaround for graphql-tools v8: |
With #4321 merged, should the issue be solved? Or some other steps are required? |
@AlexeyRaga Could you create a new issue with a reproduction if the issue still remains? Thanks! Sorry for the late response! |
Describe the bug
When I execute operation on
stitchSchemas
it doesn't forwardoperationName
to underlying schemas. We useoperationName
for logs.To Reproduce
Steps to reproduce the behavior:
https://codesandbox.io/s/naughty-franklin-b4cwd?file=/src/index.ts
Expected behavior
Operation name should forwarded to underlying schemas.
Additional context
Found this pr but it only fixed
delegateToSchema
;#1700
The text was updated successfully, but these errors were encountered: