Bug: Query Planner Fails to Build Query for Nested Entity Fields Decorated With `@requires`
Issue Description
When querying for nested entity fields decorated with @requires, a gateway for a federated graph fails to build a query plan, resulting in error "Cannot add selection of field \"X\" to selection set of parent type \"Y\"". This is a critical issue for my org.
All @apollo/* packages at latest, and composition done with latest (v2.8.4) rules.
Link to Reproduction
Reproduction Steps
- Start all services (if not already running) with:
npm run dev
- Run test query to reproduce the error with:
npm run test:query
I can reproduce this issue. The query planner is trying to overly optimize the fetch dependency graph (here), when
- the key fetch node
book @ book.notBadReads.bookfetchesidfield. - but, its (singular) parent node
not-bad-reads @ bookhas onlyisbnkey field.
The QP fails because it attempts to add an edge from the parent node to the new node (bypassing the key fetch node in the middle), assuming the key fetch node and its parent node share the same key field.
The reasoning for this optimization seems ok, but we also need to use the correct key isbn, not id.
Or, we can check this situation and fall back to the normal process (the else-branch).
Thanks, @duckki for confirming, and identifying the root cause! I just want to check in to see if there are any updates/plans regarding this issue. cc @clenfest
I've gone ahead and created a fork with a patch, but in accordance with the project contribution guidelines, would like to consult on the design before opening a PR. I agree with @duckki that the edge optimization is reasonable, and so we should just check for the cross-subgraph key condition, and look into the appropriate subgraph schema for a suitable key field to select. Please see my changes here.
FYI: The same issue is present in Apollo Router, and an issue has been opened here.
Has there been any traction on this issue? It seems to still be present, even on the latest version.
FWIW, my fork has held fast. I'll see about opening a PR.