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

Federation Gateway resolving wrong field during buildQueryPlan #3415

Closed
WardGubbi opened this issue Oct 16, 2019 · 5 comments
Closed

Federation Gateway resolving wrong field during buildQueryPlan #3415

WardGubbi opened this issue Oct 16, 2019 · 5 comments

Comments

@WardGubbi
Copy link

I'm transforming my Apollo GraphQL into a federated one and I'm seeing an issue with property types in my inline fragments being resolved incorrectly and throwing an error on the gateway

The query in question

{
  grid(
    brand: "example.com"
    path: "C4054A88-1091-41B9-A53E-0AB2706DB2B8"
    pageNumber: 1
    displaySize: SMALL
  ) {
    cells {
      __typename
      ... on GridSlider {
        spanSize
      }

      ... on GridTeaser {
        spanSize
        config {
          type
          alignment
          ratio
          numbered
          stripped
        }
      }
      
      ... on GridHtml {
        spanSize
        config {
          url
          html
        }
      }

      ... on GridBanner {
        spanSize
        config {
          adUnit
          pageType
          slot
          format
        }
      }

      ... on GridHeader {
        spanSize
        config {
          title
          color
        }
      }
    }
  }
}

This results in an error on the gateway

"GraphQLError: Cannot query field \"type\" on type \"GridTeaserConfig\"",
"    at QueryPlanningContext.getFieldDef (/Users/Ward/Projecten/mediahuis/federation-repro/node_modules/@apollo/gateway/dist/buildQueryPlan.js:381:19)",
"    at collectFields (/Users/Ward/Projecten/mediahuis/federation-repro/node_modules/@apollo/gateway/dist/buildQueryPlan.js:256:42)",

The same request does work when fed to the service itself.

In my query it will try to resolve config.url from GridHtml as a property of GridTeaserConfig (note that the previous fragment was of type GridTeaser) instead of treating config as GridHtmlConfig. When removing the GridTeaser fragment (or removing its config) the issue repeats itself on the next config, config.adUnit being resolved as property of GridHtmlConfig instead of GridBannerConfig. Reordering (or deleting some fragments) shows that it always seems to resolve to the previous type's config instead of the correct one. Keeping only one of the configs (the HTML one for example) makes it work as expected.

I'm seeing this in @apollo/gateway 0.10.4

Here is a repository (adjusted demo repo) that reproduces the behavior: https://github.com/WardGubbi/graphql-federation

@thicit
Copy link

thicit commented Oct 17, 2019

This issue seems to originate in the groups stage of the build query plan.
The field collection beforehand resolves correctly, however in the groups stage things go wrong.
completeFields & collectSubfields take the first field without considering parentType.

thicit pushed a commit to thicit/apollo-server that referenced this issue Oct 17, 2019
thicit pushed a commit to thicit/apollo-server that referenced this issue Oct 17, 2019
thicit pushed a commit to thicit/apollo-server that referenced this issue Oct 17, 2019
@geoffreysamper
Copy link

any news arround this issue

@geoffreysamper
Copy link

@thicit do you have any idea what must be done to fix this issue and get it merged?

@geoffreysamper
Copy link

This issue is fixed in #3581.

@abernix
Copy link
Member

abernix commented Jun 17, 2020

Fixed by #3581. Please report back if this isn't the case!

@abernix abernix closed this as completed Jun 17, 2020
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Apr 20, 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

No branches or pull requests

4 participants