Upgrading to @apollo/gateway 2.x while keeping Federation 1

Router
1

I’m performing an overdue upgrade of @apollo/gateway 0.x to 2.x, while keeping Federation 1 to keep it simple and incremental, then eventually upgrade to Federation 2.

I’m not sure if I’m missing some syntax to force the gateway to use federation 1, but I’m getting errors similar to the following when composing using a list of subgraph endpoints.

On field "Person.name", for @provides(fields: "Id name emailAddress "): field Person.name cannot be included because it has arguments (fields with argument are not allowed in @provides)

Is there a specific version of @apollo/gateway upto which Federation 1 is supported?
What’s the syntax to force using Federation 1 in @apollo/gateway ?

The page that mentions the backwards compatibility, but I can’t find more information.

2

Gateway v2.x supports both Fed 1 (aka 0.x) and Fed 2. There is no “mode” you have to put the gateway in because what determines what Federation version you use is your supergraph file which is the output from composition at build time.

I would recommend using rover supergraph compose to build this file.

federation_version: 1
subgraphs:
  foobar:
    routing_url: http://localhost:4001/graphql
    schema:
      file: schema.graphql

Your error that you are seeing is an error because the @provides directive can not resolve fields that require arguments dynamically. See your error message:

Person.name cannot be included because it has arguments (fields with argument are not allowed in @provides)
3

Thanks for the reply. I don’t get the @provides error with apollo gateway 0.x, but I do with 2.x.
To fix the error by removing the argument will be a breaking change, while its mentioned that upgrading the gateway should be backward compatible. Is there no way to avoid / override the error and proceed with the same schema?

4

You will need to compose your supergraph with Federation 1 and then you can pass that Fed 1 supergraph to Gateway 2.x

5

I tried that. Rover is able to compose the supergraph, but I get the same federation 2 validation errors when using @apollo/gateway 2.x with the supergraph file, as when I had used composition with @apollo/gateway 2.x directly

KEY_FIELDS_HAS_ARGS
KEY_INVALID_FIELDS
PROVIDES_FIELDS_HAS_ARGS
PROVIDES_INVALID_FIELDS

6

@sgarg7 You should not be getting Fed 2 composition errors if you are using Fed 1 as your federation_version in the supergraph config.

Can you please make sure that you are setting that up all correctly and then if it still is not working share your files here for reproduction.

7

Yes, I’m using the --federation-version 1 cli option and also the supergraph config file option for rover.
It’s not the rover supergraph compose.. command that gives errors, it’s running the gateway using @apollo/gateway using the generated supergraph file that gives me one error right now, and I believe it will return the other errors also mentioned above, once I fix this one.
Out of them, I think the PROVIDES_FIELDS_HAS_ARGS error needs a schema fix that can break existing queries.

I’ll come up with a representative schema that returns the same errors when run with the gateway.

Gateway successfully initialized (but not yet loaded)
Loading gateway...
node:internal/process/promises:289
            triggerUncaughtException(err, true /* fromPromise */);
            ^

GraphQLError: Invalid empty selection set for field "ServiceHours.hours" of non-leaf type [ServiceHoursTime!]!
8

apologies, haven’t gotten back to this, will send a reproducible schema when I do.