-
Notifications
You must be signed in to change notification settings - Fork 268
fix(query-planner): Fix bug where subgraph jump key fields are fetched from the wrong group #3293
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
fix(query-planner): Fix bug where subgraph jump key fields are fetched from the wrong group #3293
Conversation
🦋 Changeset detectedLatest commit: e30a72d The changes in this PR will be included in the next version bump. This PR includes changesets to release 7 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
✅ Docs preview has no changesThe preview was not built because there were no changes. Build ID: 287ee4595aed4e5c0f26fb00 |
|
This pull request is automatically built and testable in CodeSandbox. To see build info of the built libraries, click here or the icon next to each commit SHA. |
e1bd537 to
4a31e5a
Compare
duckki
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It makes sense. But, I just have a question.
610e7b9 to
efe5b99
Compare
…nly try to collect its key fields from a subgraph that didn't have them.
efe5b99 to
3d51c1d
Compare
3d51c1d to
e30a72d
Compare
…s are fetched from the wrong node (#8016) When a `@requires` edge needs a subgraph jump during fetch dependency graph processing, this would sometimes cause the locally satisfiable key fields needed by that jump to be fetched from the parent node instead of the current node (which apparently was done as an optimization). This can be a problem, since `GraphPath::can_satisfy_conditions()` only really guarantees the current node has those key fields. This PR updates the code using the parent node to now explicitly check whether the locally satisfiable key can be fetched from that node, and if not, falls back to the current node (adding it as a parent, if needed). This lets us keep the optimization and avoid unnecessarily changing query plans. This PR mirrors its JS equivalent at apollographql/federation#3293 , and fixes #6004 .
When a
@requiresedge needs a subgraph jump, this would sometimes cause the locally satisfiable key fields needed by that jump to be fetched from the parent group instead of the current group (which apparently was done as an optimization). This can be a problem, sincecanSatisfyConditions()only really guarantees the current group has those key fields.This PR updates the code using the parent group to now explicitly check whether the locally satisfiable key can be fetched from that group, and if not, falls back to the current group (adding it as a parent, if needed). This lets us keep the optimization and avoid unnecessarily changing query plans.
Fixes #3113 and #2987 , and derives a simpler example test from the one given in #3246 .