generateQueryFragments generates invalid plans with missing fragment definitions #2993
Conversation
👷 Deploy request for apollo-federation-docs pending review.Visit the deploys page to approve it
|
🦋 Changeset detectedLatest commit: c65cb04 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 |
| y | ||
| } | ||
|
|
||
| fragment _generated_onA2_1 on A { |
There was a problem hiding this comment.
This fragment is missing in practice.
|
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. |
internals-js/src/operations.ts
Outdated
| } | ||
| namedFragments.add(fragmentDefinition); |
There was a problem hiding this comment.
If we get here, it's because we didn't find an exact match. In these cases, we need to create a fragment definition in all cases. Double check me here, but this does seem to fix the issue.
There was a problem hiding this comment.
Yeah, agree. Small nit, but could we bump this line up to where fragmentDefinition is assigned? Probably makes more sense right next to it.
Appreciate the if/else restructure 👍
xuorig
force-pushed
the
generate-fragment-aliases-bug
branch
from
ed80be0
to
f7644ed
Compare
internals-js/src/operations.ts
Outdated
| } | ||
| namedFragments.add(fragmentDefinition); |
There was a problem hiding this comment.
Yeah, agree. Small nit, but could we bump this line up to where fragmentDefinition is assigned? Probably makes more sense right next to it.
Appreciate the if/else restructure 👍
|
Addressed your comments @trevor-scheer 🙇 thanks for the quick review! |
.changeset/stupid-lemons-rest.md
Outdated
| "@apollo/query-planner": patch | ||
| --- | ||
|
|
||
| Fix issue with missing fragment definitions due to generateQueryFragments |
There was a problem hiding this comment.
I can't send this as a GH suggestion due to use of triple backtick in the comment, but would you mind adding this or something like it?
Fix issue with missing fragment definitions due to generateQueryFragments
An incorrect impementation detail in
generateQueryFragmentscaused certain queries to be missing fragment definitions. Specifically, subsequent fragment "candidates" with the same type condition and the same length of selections as a previous fragment weren't correctly added to the list of fragments. An example of an affected query is:query { t { ... on A { x y } } t2 { ... on A { y z } } }In this case, the second selection set would be converted to an inline fragment spread to subgraph fetches, but the fragment definition would be missing.
There was a problem hiding this comment.
Ideally the changeset should have the ```graphql code fencing around the query, but that doesn't paste over from my comment.
xuorig
force-pushed
the
generate-fragment-aliases-bug
branch
from
6aeb8d1
to
c65cb04
Compare
This PR was opened by the [Changesets release](https://github.com/changesets/action) GitHub action. When you're ready to do a release, you can merge this and the packages will be published to npm automatically. If you're not ready to do a release yet, that's fine, whenever you add more changesets to main, this PR will be updated. # Releases ## @apollo/[email protected] ### Patch Changes - Updated dependencies \[]: - @apollo/[email protected] - @apollo/[email protected] ## @apollo/[email protected] ### Patch Changes - Updated dependencies \[[`af4376f348d21ad4d8eca0e3d2a170600f391e4d`](af4376f)]: - @apollo/[email protected] - @apollo/[email protected] - @apollo/[email protected] ## @apollo/[email protected] ### Patch Changes - Updated dependencies \[]: - @apollo/[email protected] ## @apollo/[email protected] ### Patch Changes - Fix issue with missing fragment definitions due to `generateQueryFragments`. ([#2993](#2993)) An incorrect implementation detail in `generateQueryFragments` caused certain queries to be missing fragment definitions. Specifically, subsequent fragment "candidates" with the same type condition and the same length of selections as a previous fragment weren't correctly added to the list of fragments. An example of an affected query is: ```graphql query { t { ... on A { x y } } t2 { ... on A { y z } } } ``` In this case, the second selection set would be converted to an inline fragment spread to subgraph fetches, but the fragment definition would be missing. - Updated dependencies \[]: - @apollo/[email protected] - @apollo/[email protected] ## @apollo/[email protected] ### Patch Changes - Updated dependencies \[]: - @apollo/[email protected] ## @apollo/[email protected] ## [email protected] Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
This PR includes a failing test that show that
generateQueryFragmentscan generate invalid GraphQL queries. It seems related to the way the hashCode is computed. Any selections of the same length and type are somehow grouped together and an additional fragment definition is not added.Opening this in case somebody gets to the root cause fix while I investigate further.