apollo-federation-ruby: v3.4.x updates federation directive version to 2.3, fails schema checks with Apollo Studio

Howdy! We updated this gem to 3.4.1 in one of our subgraphs, and its schema verification is failing in Apollo Studio. Here are some results:

Generated Schema snippet:

extend schema
  @link(url: "https://specs.apollo.dev/federation/v2.3", import: ["@inaccessible"])

type Something @federation__extends @federation__key(fields: "id") {
  id: ID! @federation__external
  ...
}

Apollo Studio Check output:

UNKNOWN_FEDERATION_LINK_VERSION
[x-service] Invalid version v2.3 for the federation feature in @link direction on schema
INVALID_GRAPHQL
[x-service] Unknown directive "@federation__external".
INVALID_GRAPHQL
[x-service] Unknown directive "@federation__extends".
INVALID_GRAPHQL
[x-service] Unknown directive "@federation__key".

Our supergraph is configured in Apollo Studio to use Federation version 2.0.

Our subgraphs also specify the Federation version using this gem. It seems like that version specification is being ignored when generating the @link directive.

I’m looking at this code change 👀 https://github.com/Gusto/apollo-federation-ruby/commit/c7b987de1d2b32a4a77ceb09718373ffa5a60abb#diff-48d1e38dfab06335bc60255c48ef179d40143d14e29cfb52673b258346799900R64

Shouldn’t that be honoring the federation_version value?

About this issue

Original URL
State: open
Created a year ago
Reactions: 2
Comments: 17 (4 by maintainers)

Commits related to this issue

docs(changelog): add breaking change to 3.4.0 This adds information to v3.4.0 highlighting the breaking change to composition discussed in #221 and providing guidance on how to proceed. — committed to jmpage/apollo-federation-ruby by jmpage a year ago
docs(changelog): add breaking change to 3.4.0 This adds information to v3.4.0 highlighting the breaking change to composition discussed in #221 and providing guidance on how to proceed. — committed to jmpage/apollo-federation-ruby by jmpage a year ago
docs(changelog): add caveat to 3.4.0 This adds information to v3.4.0 highlighting the breaking change to composition discussed in #221 and providing guidance on how to proceed. — committed to jmpage/apollo-federation-ruby by jmpage a year ago
docs(changelog): add caveat to 3.4.0 (#258) This adds information to v3.4.0 highlighting the breaking change to composition discussed in #221 and providing guidance on how to proceed. — committed to Gusto/apollo-federation-ruby by jmpage a year ago

Most upvoted comments

FYI we just published Graph update guide

dariuszkuc on Feb 24, 2023

@karmingc in case it’s helpful to you: I have not experienced any issues in a large federated graph from bumping the composition version to the latest one in Apollo Studio and then allowing subgraphs to opt into the current version supported by this library.

jmpage on Dec 6, 2023

@karmingc If you are able to update the composition version in your router/gateway and in Apollo Studio, you should be able to unblock yourselves on this. I think based on the guidance from some Apollo folks, we will probably only support a single major version of federation with this library, at least for now. PRs are always welcome, of course, but as @jmpage mentioned above, we are only in an as-needed maintenance phase as the team has other priorities at the moment.

grxy on Dec 6, 2023

thanks for the reference @jmpage!

karmingc on Dec 6, 2023

@karmingc, per #267:

For now, we’ve decided our maintenance of this gem is unlikely to extend beyond simple changes, such as bug patches, dependency bumps, and very minor tweaks. More significant changes, such as breaking changes, new features, or alterations to fundamental internal logic will be deprioritized.

There is also a new team which owns this gem, as mentioned in a comment on that issue.

jmpage on Dec 6, 2023

Should bumps of the federation version to v2.1, v2.2, and v2.3 when upgrading apollo-federation-ruby be considered breaking changes in so much as they can cause composition to fail in Apollo Studio if the graph isn’t yet configured to support that version and there is no option to opt into a specific 2.x version of federation?

Would you mind if I PRed an update to the changelog which explicitly states at which versions of this gem that federation 2.x+ is bumped to the next version?

jmpage on Jul 13, 2023

Looking at graphql-kotlin as an example, they implemented this using an opt-in boolean for Federation 2, and the version of federation is something that they hard code and include in their release notes.

I still think I prefer letting each subgraph (as a consumer of this gem) decide which version of federation they’re declaring support for. These are some points that I think about:

As a configuration option, the federation version is something a subgraph can be explicit about; it does not update unless the maintainer chooses to update it
New releases of this gem could focus mainly on functionality (new directives, changes to the federation spec) without influencing consumers’ choice of adoption of that new functionality
A boolean option for “Use Federation 2” is only good as long as the condition holds that “I want Federation > 1”. What happens when Federation 3 comes into the mix?
Rolling a new release of this gem for each new version of the Federation spec is somewhat gatekeep-y; why is it important to intermediate that with the consumers?
How do you determine what semantic version of this gem to change for a new Federation version? As this issue highlights, even a minor version of Federation changing in the @link directive can be a “breaking change” in the sense that your supergraph build can fail if it’s not up to the latest version.

lyricsboy on Feb 24, 2023

I opened https://github.com/Gusto/apollo-federation-ruby/pull/222 as a proposed fix for this.

lyricsboy on Feb 23, 2023