How can I avoid federation schema mismatch during composition?

Let’s assume the following example while using v2 of all the nifty apollo npm packages

# subgraph A
type Customer @key(fields: "id") {
  id: Int!
  name: String!
}

type Query {
  customer(id: Int!): Customer
}

# subgraph B
type Invoice @key(fields: "id") {
  id: Int!
  amount: Int!
}

type Customer @key(fields: "id") {
  id: Int!
  invoices: [Invoice!]!
}

my problem is, if I only use this, buildSchema will assume fed1 and so will decide on a query plan that might be pointing at subgraph B because it cannot make out the correct one.
ok no problem, when I try to add

extend schema @link( url: "https://specs.apollo.dev/federation/v2.0" import: ["@key", "@shareable", "@external", "@override", "@requires"] )

to have fed2 version of @key directive for example I get this conflicting error

Invalid definition for directive "@key": argument "fields" should have type "federation__FieldSet!" but found type "_FieldSet!"

Invalid definition for directive "@requires": argument "fields" should have type "federation__FieldSet!" but found type "_FieldSet!"

I can then add the directive explicitly but it will always errors on not having the other of the possible fieldset options.

Obviously, when I let the gateway only have one graph the resolution works as expected, as soon as the gateway catches wind on the extension of the type sin subgraph b it breaks.

do I need to specify the fed version in every subgraph?
if I have a modular subgraph, do I have to specify it in every partial of a subgraph?
Since I only get UNKNOWN error in rover, is there an error message for federation version mismatch?

@hinogi was able to solve the issue :partying_face: ! The problem was related to some schema merging conflicts.

For the record, I did do a quick prototype of the above schemas using the latest Apollo Server and they work as-is with fed1.

1 Like