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.
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.
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)
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?
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
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!]!
Created a minimal reproduction schema for this issue here
The supergraph has been composed with rover supergraph compose --config supergraph-config.yaml --federation-version 1 > supergraph.schema.graphql
this does not generate composition errors but running node gateway.js shows the following error -
❯ node gateway.js
~/test-schema/node_modules/@apollo/federation-internals/dist/extractSubgraphsFromSupergraph.js:201
throw new Error(`${msg}.\n\nDetails:\n${errorToString(error)}`);
^
Error: Error extracting subgraph "accounts" from the supergraph: this might be due to errors in subgraphs that were mistakenly ignored by federation 0.x versions but are rejected by federation 2.
Please try composing your subgraphs with federation 2: this should help precisely pinpoint the problems and, once fixed, generate a correct federation 2 supergraph.
Details:
[accounts] On type "User", for @key(fields: "id(format:\"uuid\")"): field User.id cannot be included because it has arguments (fields with argument are not allowed in @key)
at extractSubgraphsFromSupergraph (~/test-schema/node_modules/@apollo/federation-internals/dist/extractSubgraphsFromSupergraph.js:201:19)
at Supergraph.subgraphs (~/test-schema/node_modules/@apollo/federation-internals/dist/supergraphs.js:137:107)
at buildFederatedQueryGraph (~/test-schema/node_modules/@apollo/query-graphs/dist/querygraph.js:259:34)
at new QueryPlanner (~/test-schema/node_modules/@apollo/query-planner/dist/buildPlan.js:1785:80)
at ApolloGateway.updateWithSchemaAndNotify (~/test-schema/node_modules/@apollo/gateway/dist/index.js:436:29)
at ApolloGateway.updateWithSupergraphSdl (~/test-schema/node_modules/@apollo/gateway/dist/index.js:416:18)
at ApolloGateway.externalSupergraphUpdateCallback (~/test-schema/node_modules/@apollo/gateway/dist/index.js:366:18)
at ApolloGateway.initializeSupergraphManager (~/test-schema/node_modules/@apollo/gateway/dist/index.js:338:18)
at async ApolloGateway.load (~/test-schema/node_modules/@apollo/gateway/dist/index.js:244:13)
at async SchemaManager.start (~/test-schema/node_modules/@apollo/server/dist/cjs/utils/schemaManager.js:37:28)
Node.js v20.14.0
This is the KEY_FIELDS_HAS_ARGS error
Notice the line
his might be due to errors in subgraphs that were mistakenly ignored by federation 0.x versions but are rejected by federation 2.
this also means the gateway is trying to parse the schema as federation 2 not federation 1 or 0.x
@sgarg7 Thank you for sharing the reproduction. That was much easier to find an answer. It appears you have uncovered an edge case and something that arose from our migration from Fed 1 to 2.
This scenario was techinically not supported in Fed 1 but just not caught by composition. In Fed 1 we just never had any checks for this scenario and since it was already in place we couldn’t break schemas without asking you to update to Fed 2.
Since the key value parsing requires some args it does not guarentee that value is the same even if hardcoded. This is not allowed in Fed 2 as it makes query planning “guaranteed” to be deterministic. This does need to be indicated in the migration docs.
To fix this, you are going to have to add a new key that does not require any args. Since this is a static value that you pass in it should be easy enough to add a new field that on the backend does the same logic always with “uuid” as the format