Skip to content

Correctly expand possible types for interfaces #3529

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

Merged
merged 6 commits into from
Nov 20, 2019

Conversation

trevor-scheer
Copy link
Contributor

@trevor-scheer trevor-scheer commented Nov 19, 2019

This PR is in response to the following contributions made by @vitramir, thank you for bringing this to our attention and proposing a solution 🎉
Closes #3253
Closes #3257

Thank you to everyone following along for your patience while we've discussed the problem and a solution we'd like to go forward with. @martijnwalraven has prepared this branch for us as a proposal, and it's one we'd like to go forward with.

This PR introduces the concept of a Scope. A Scope (which belongs to a Field) captures information about the parent's type and the possible types of the Field. This addition to the data model of a Field allows the query planner to make correct decisions about exploding interfaces into only possible types.

Copy link

@queerviolet queerviolet left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks great! 👍🏽

For future work, it strikes me that the solution to this general problem—given a point in a query, what fields / fragments are valid?—might well be useful in other contexts (like a language server, for example), so it might be worth pulling out at some point. Either way, this is great for the gateway, so LGTM.

@@ -93,69 +93,69 @@ describe('buildQueryPlan', () => {
const queryPlan = buildQueryPlan(buildOperationContext(schema, query));

expect(queryPlan).toMatchInlineSnapshot(`
QueryPlan {

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

aw man this indentation change is a bummer.

(tests are not a bummer, tests are great, i'm just sad abt that jest bug)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good news is the bug is behind us and our poorly indented tests will resolve themselves over time 😄

@@ -422,14 +426,14 @@ function splitFields(
GraphQLObjectType
>();

for (const runtimeParentType of context.getPossibleTypes(parentType)) {
for (const runtimeParentType of scope.possibleTypes) {

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ahhh, so nice. ♨️😄

@trevor-scheer trevor-scheer merged commit 43d3ac1 into master Nov 20, 2019
@trevor-scheer trevor-scheer deleted the query-planner-fixes branch November 20, 2019 01:05
abernix pushed a commit to apollographql/federation that referenced this pull request Sep 4, 2020
…server#3529)

* Fix indentation of query plan snapshots in test

* Add failing tests from apollographql/apollo-server#3257

* Introduce Scope to capture nested type conditions

* Clarify that `completeField` is only called for object types

* Adjust fields when expanding possible types

Co-authored-by: Martijn Walraven <[email protected]>
Co-authored-by: Vitramir <[email protected]>
Apollo-Orig-Commit-AS: apollographql/apollo-server@43d3ac1
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Mar 16, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Why does the gateway expand interface fragment into multiple implementations fragments? (federation)
3 participants