fix: owned types are marked as extension when GraphQL `v16` is used

[Gamote]

This PR is meant to fix the issues in which types are wrongly set as extensions when GraphQL v16 is used.

Issue printSubgraphSchema.ts:190 (@apollo/subgraph) checks if the extensionASTNodes field is defined in order to determine if a type should be extended or not. GraphQL v15 sets it as undefined while GraphQL v16 always includes extensionASTNodes in all GraphQLObjectType as [].

Fix I order to fix this we had to also check the length of the array, not only just if it's defined.

This will also fix: #2029.

Let me know if you need more details. We will provide any information in order to speed up the process of releasing the fix as this is a major issue for consumers that are using Federation.

[apollo-cla]

@Gamote: Thank you for submitting a pull request! Before we can merge it, you'll need to sign the Apollo Contributor License Agreement here: https://contribute.apollographql.com/

[codesandbox-ci[bot]]

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.

[trevor-scheer]

On second thought, given that this change is targeting a v15/v16 incompatibility, this PR should be opened against the version-0.x branch. The 0.x versions of federation packages claim support for both v15 and v16 versions of graphql (and also run build and test against v15 as well). The main line (which represents federation 2) of this repo only claims support for v16.

I was pretty curious to see if there were any issues so I cherry-picked your commits over to a branch on top of version-0.x and it all looks good! You're welcome to use it directly or mimic the changes. https://github.com/apollographql/federation/tree/trevor/fix-extensions-v16

[Gamote]

@trevor-scheer Thank you for the insights. I will soon make the requested changes + tests.

Regarding the version-0.x branch, if I understand correctly this PR should target it. But what will happen with the main line as it has the same issue. Should we have a separated PR that mimics this one but with changes/tests that aim just for v16 support?

[trevor-scheer]

@Gamote yep - you're welcome to open both PRs if you like, or leave it to me to port the change over to main. Totally up to you! In any case we'll get this fixed in both places.

[vinaybedre]

@Gamote can you please continue with your changes? This is blocking at least some of us, who would like to use @apollo/subgraph with graphql v16.

[kdawgwilk]

@Gamote Do you think you'll have bandwidth to continue working on this? If not I would be willing to pick this up

[Gamote]

Hi @kdawgwilk, if you can please do. I really can't find the time to allocate to this issue. I appreciate 🙏

[SirReiva]

Any update?

[kdawgwilk]

Unfortunately had a few changes in priorities and its going to be a month or so until I will have a chance to look at this

[adamlarsonlee]

FYI - I was getting this issue on a Federation 1 subgraph and this issue went away completely by upgrading my graphql related packages and switching to @apollo/subgraph from @apollo/federation. Basically upgrade to Federation 2 and this shouldn't be a problem for you.

[trevor-scheer]

I'm going to optimistically close this based on @adamlarsonlee 's comment, but I'm happy to reopen if this is still ongoing in latest versions of subgraph/gateway packages.