Interface explosion issue with Fed1 supergraph/Fed2 query planner

[lennyburdette]

Reproduction: https://stackblitz.com/edit/basic-federation-xfmlkb?file=fed1-supergraph.graphql,README.md

The customer is trying to upgrade to Gateway 2.0 with their existing fed 1 supergraph. The query planner is improperly exploding the interface to include conditional fragments for all implementations of the interface. (In the original schemas, there are dozens of possible types so the query plan is enormous.)

QueryPlan {
  Fetch(service: "customer-name") {
    {
      profile(uuid: $profile_id) {
        suggestions(sequential: false) {
          nodes {
            suggestedObject {
              __typename
              ... on NewsfeedCard_FeaturedComment {
                id
              }
              ... on Profile {
                id
              }
              ... on Profiles_Suggestion {
                id
              }
            }
          }
        }
      }
    }
  },
}

This causes a runtime error because the subgraph doesn't include all the implementations. I included a second subgraph to show that runtime failure, but the query planner is generating unnecessary conditional fragments even without the second subgraph.

Everything works with a Fed 2 supergraph — the query plan includes no conditional fragments.

[pcmanus]

So yes, fed2 with fed1 supergraphs does type-explosion of interfaces in some cases where the fed1 query planner wasn't and that's an oversight (which gets in the way of upgrades).

That is, fed1 always type-explode an interface if any of the implementation is an entity type, but doesn't if all said implementations are value types (the case in this example). But current fed2 with fed1 supergraph currently always type-explode instead.

Anyway, while we can mimick that fed1 behaviour in fed2-with-fed1-supergraphs, attached a PR that instead just remove the special we were making for fed1 supergraph, thus making it behave like fed2 with fed2 supergraphs. Because upon reflexion, I believe that's actually fine, and the fed2 rule (which consider type-explosion separately for each field, and only force type-explosion if ) is a bit "better" (it type-explode less often, a good thing) than the fed1 one.

The query planner is improperly exploding the interface to include conditional fragments for all implementations of the interface.

For the sake of knowledge dissemination, I'll point out that while we can avoid exploding into types here (and this does provides a way out of this particular example), the fact that when it explodes, it (incorrectly) explodes into all implementations is not something we can really fix. Because if you look at the supergraph (which is the only input of the query planner), there is actually no information about where (in which subgraphs) the interface and implementation types are defined.

This is why fed2 "upgraded" supergraphs (to include that kind of information) and it does lead to cases where both fed1 and fed2-with-fed1-supergraphs query planners are generating invalid plans (that fail at runtime). For instance, in the example of this issue, if you simply add a @key to the NewsfeedCard_FeaturedComment type in the 2nd subgraph (without changing the 1st one at all), you'll see that the plan generated by fed1 does type explosion and is broken. Obviously, since fed1 fails on such cases in the first place, users won't have relied on such example in fed1 and it's not an issue for upgrades (just a limitation of fed1 that is fixed by upgrading to fed2 and recomposing into a fed2 supergraph), but just wanted to point out that there is known limitations due to fed1 supergraph having incomplete information.