fix(query-planner): Fix bug where subgraph jump key fields are fetched from the wrong group#3293
Merged
sachindshinde merged 3 commits intomainfrom Aug 1, 2025
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. |
sachindshinde
force-pushed
the
sachin/fix-inapplicable-key-during-requires-subgraph-jump
branch
from
e1bd537 to
4a31e5a
Compare
duckki
reviewed
Jul 29, 2025
Contributor
duckki
left a comment
duckki
left a comment
There was a problem hiding this comment.
It makes sense. But, I just have a question.
sachindshinde
force-pushed
the
sachin/fix-inapplicable-key-during-requires-subgraph-jump
branch
from
610e7b9 to
efe5b99
Compare
…nly try to collect its key fields from a subgraph that didn't have them.
sachindshinde
force-pushed
the
sachin/fix-inapplicable-key-during-requires-subgraph-jump
branch
from
efe5b99 to
3d51c1d
Compare
sachindshinde
force-pushed
the
sachin/fix-inapplicable-key-during-requires-subgraph-jump
branch
from
3d51c1d to
e30a72d
Compare
duckki
approved these changes
Jul 31, 2025
sachindshinde
deleted the
sachin/fix-inapplicable-key-during-requires-subgraph-jump
branch
sachindshinde
added a commit
to apollographql/router
that referenced
this pull request
Oct 1, 2025
…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 .
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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 .