Skip to content
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

Bug: Query Planner Fails to Build Query for Nested Entity Fields Decorated With @requires #3113

Open
ryan01010111 opened this issue Aug 12, 2024 · 4 comments

Comments

@ryan01010111
Copy link

ryan01010111 commented Aug 12, 2024

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

CodeSandbox

Reproduction Steps

  1. Start all services (if not already running) with:
npm run dev
  1. Run test query to reproduce the error with:
npm run test:query
@duckki
Copy link
Contributor

duckki commented Aug 13, 2024

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.book fetches id field.
  • but, its (singular) parent node not-bad-reads @ book has only isbn key field.

image

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).

@ryan01010111
Copy link
Author

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

@ryan01010111
Copy link
Author

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.

@ryan01010111
Copy link
Author

FYI: The same issue is present in Apollo Router, and an issue has been opened here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants