apollographql
@requires field always resolved from same subgraph
Issue Description
If one subgraph @requires a field to resolve another field, and that other field is @shareable defined in multiple subgraphs, the query plan seems to arbitrarily pick one subgraph to resolve the shareable field everytime.
This results in a less performant query plan because even if the subgraph that is resolving the query can resolve the @shareable field as well, the query plan still includes the third subgraph just to resolve the shareable field.
Included in the reproduction project I also use @provides to explicitly provide the required field and yet it is still not resolved from the expected subgraph.
I would expect that @shareable would build the most efficient query plan automatically, but especially would expect it when explicitly defining the query plan by using @provides.
Link to Reproduction
https://github.com/joshfoeh-bill/apollo-query-plan
Reproduction Steps
Reproduction steps included in readme of attached repo.
@joshfoeh-bill I'm facing the same problem. Could you let me know if you were able to resolve this? Or did you find a workaround?
@gaurav-dhero Unfortunately not. I ended up removing the field from the third subgraph that was erroneously resolving the field. In our case we didn't actually need the field in that third subgraph so that worked for us.
we experience the same issue but we actually have a usecase for this. Wondering if anyone reading this has solved it one way or another.
This is an interesting query plan optimization idea. The current implementation only plans forward from the point where it sees the @requires directives. But, a better plan could be piggy-backing required fields from the previous fetch.
UPDATE:
Normally, the query planner optimizes the plan by fetching required fields before jumping from one subgraph to another. But it appears that there is a gap in that optimization when the required field happens to be a @shareable field. That's my conjecture. Further investigation will be needed to confirm that.
@duckki That is pretty much the issue we have. Eg. we have a Restaurant which has an ExpeditionType which could be either Delivery or Pickup and this can change based on the Context of the page the user is looking at. Another Subgraph which is resolving the DeliveryTime for these Restaurants needs to know which ExpeditionType that Restaurant has in the context of this page. ExpeditionType is a shareable field and there is no Subgraph "owning" it as it can have different values based on context. If a client now fetches ExpeditionType from the first Subgraph which is determining it based on said context, it then should pass that value to the Subgraph which resolves the DeliveryTime, however what actually happens is that the router seemingly arbitrarily picks a Subgraph to fetch the field without realising it already has it in hand which then can lead to invalid results.