Apollo Federation Error Codes
Reference for composition error codes
When GraphOS attempts to compose your subgraph schemas into a supergraph schema, it confirms that:
The subgraphs have valid GraphQL and Federation syntax
The resulting supergraph schema is valid
The graph router or gateway has all of the information it needs to execute operations against the resulting schema
If composition fails, a new supergraph schema cannot be generated. This document lists subgraph validation and composition error codes, along with their root causes.
ⓘ note
Composition may flag potential improvements or hints on schemas which are technically valid. These hints aren't errors, and are instead logged as part of the composition build step.
To learn more, see the composition hints doc.
Errors
The following errors might be raised during composition:
| Error Code / Minimum Federation Version |
Description |
|---|---|
Since v2.0.0 | An element is marked as @inaccessible but is used in the default value of an element visible in the API schema. |
Since v2.1.0 | Error when composing custom directives. |
Since v2.0.0 | A built-in or Federation directive has an invalid definition in the schema.Replaces TAG_DEFINITION_INVALID. |
Since v2.0.0 | An element is marked as @inaccessible that is not allowed to be @inaccessible. |
Since v0.x | Indicates an error in a subgraph service query during query execution in a federated service. |
Since v2.0.0 | An enum type has no value common to all the subgraphs that define the type. Merging that type would result in an invalid empty enum type. |
Since v2.0.0 | An input object type has no field common to all the subgraphs that define the type. Merging that type would result in an invalid empty input object type. |
Since v2.0.0 | An enum type that is used as both an input and output type has a value that is not defined in all the subgraphs that define the enum type. |
Since v0.x | A subgraph is attempting to extend a type that is not originally defined in any known subgraph. |
Since v2.0.0 | An @external field declares an argument with a default that is incompatible with the corresponding argument in the declaration(s) of that field in other subgraphs. |
Since v2.0.0 | An @external field is missing some arguments present in the declaration(s) of that field in other subgraphs. |
Since v2.0.0 | An @external field declares an argument with a type that is incompatible with the corresponding argument in the declaration(s) of that field in other subgraphs. |
Since v2.1.0 | The @external directive collides with other directives in some situations. |
Since v0.x | A field is marked as @external in a subgraph but with no non-external declaration in any other subgraph. |
Since v2.0.0 | The field of an interface type is marked with @external: as external is about marking field not resolved by the subgraph and as interface field are not resolved (only implementations of those fields are), an "external" interface field is nonsensical |
Since v0.x | An @external field has a type that is incompatible with the declaration(s) of that field in other subgraphs. |
Since v0.x | An @external field is not being used by any instance of @key, @requires, @provides or to satisfy an interface implementation. |
Since v2.0.0 | An argument (of a field/directive) has a default value that is incompatible with that of other declarations of that same argument in other subgraphs. |
Since v2.0.0 | An argument (of a field/directive) has a type that is incompatible with that of other declarations of that same argument in other subgraphs.Replaces VALUE_TYPE_INPUT_VALUE_MISMATCH. |
Since v2.0.0 | A field has a type that is incompatible with other declarations of that field in other subgraphs.Replaces VALUE_TYPE_FIELD_TYPE_MISMATCH. |
Since v2.0.0 | An element is marked as @inaccessible but implements an element visible in the API schema. |
Since v2.0.0 | An input field has a default value that is incompatible with other declarations of that field in other subgraphs. |
Since v2.0.0 | After subgraph merging, an implementation is missing a field of one of the interfaces it implements (which can happen for valid subgraphs). |
Since v2.3.0 | A subgraph has a @key on an interface type, but that subgraph does not define an implementation (in the supergraph) of that interface. |
Since v2.3.0 | A @key is defined on an interface type, but is not defined (or is not resolvable) on at least one of the interface implementations. |
Since v2.3.0 | Error in the usage of the @interfaceObject directive. |
Since v2.1.0 | Indicates that a schema provided for an Apollo Federation supergraph is not a valid supergraph schema. |
Since v2.0.0 | A field that is non-shareable in at least one subgraph is resolved by multiple subgraphs. |
Since v2.0.0 | A schema is invalid GraphQL: it violates one of the rules of the specification. |
Since v2.0.0 | An application of the @link directive is invalid/does not respect the specification. |
Since v2.1.0 | A URL/version for a @link feature is invalid/does not respect the specification. |
Since v2.1.2 | The @shareable Federation directive is used in an invalid way. |
Since v2.0.0 | A subgraph name is invalid. (Subgraph names cannot be a single underscore (_)). |
Since v2.1.0 | The fields argument of a @key directive includes some directive applications. This is not supported. |
Since v2.0.0 | The fields argument of a @key directive includes a field defined with arguments (which is not currently supported). |
Since v0.x | The fields argument of @key directive includes a field whose type is a list, interface, or union type. Fields of these types cannot be part of a @key. |
Since v2.0.0 | The value passed to the fields argument of a @key directive is not a string. |
Since v2.0.0 | The fields argument of a @key directive is invalid (it has invalid syntax, includes unknown fields, ...). |
Since v2.0.0 | A @key directive is used on an interface, which is only supported when @linking to Federation v2.3 or later. |
Since v2.0.0 | The import name for a merged directive (as declared by the relevant @link(import:) argument) is inconsistent between subgraphs. |
Since v2.0.0 | In a subgraph, a field is both marked @external and has a merged directive applied to it. |
Since v2.0.0 | None of the composed subgraphs expose any query. |
Since v2.0.0 | A type visible in the API schema has only @inaccessible children. |
Since v2.0.0 | The @override directive cannot be used on external fields, nor to override fields with either @external, @provides, or @requires. |
Since v2.0.0 | Field with @override directive has "from" location that references its own subgraph. |
Since v2.7.0 | The @override directive label argument must match the pattern /^[a-zA-Z][a-zA-Z0-9_-:./]*$/ or /^percent((d{1,2}(.d{1,8})?|100))$/. |
Since v2.3.0 | The @override directive cannot be used on the fields of an interface type. |
Since v2.0.0 | Field which is overridden to another subgraph is also marked @override. |
Since v2.1.0 | The fields argument of a @provides directive includes some directive applications. This is not supported. |
Since v2.0.0 | The fields argument of a @provides directive includes a field defined with arguments (which is not currently supported). |
Since v0.x | The fields argument of a @provides directive includes a field that is not marked as @external. |
Since v2.0.0 | The value passed to the fields argument of a @provides directive is not a string. |
Since v2.0.0 | The fields argument of a @provides directive is invalid (it has invalid syntax, includes unknown fields, ...). |
Since v2.0.0 | A @provides directive is used to mark a field whose base type is not an object type. |
Since v2.0.0 | A @provides directive is used on an interface, which is not (yet) supported. |
Since v2.0.0 | An element is marked as @inaccessible but is the query root type, which must be visible in the API schema. |
Since v2.0.0 | An element is marked as @inaccessible but is referenced by an element visible in the API schema. |
Since v2.0.0 | An argument of a field or directive definition is mandatory in some subgraphs, but the argument is not defined in all the subgraphs that define the field or directive definition. |
Since v2.0.0 | An element is marked as @inaccessible but is required by an element visible in the API schema. |
Since v2.0.0 | A field of an input object type is mandatory in some subgraphs, but the field is not defined in all the subgraphs that define the input object type. |
Since v2.1.0 | The fields argument of a @requires directive includes some directive applications. This is not supported. |
Since v0.x | The fields argument of a @requires directive includes a field that is not marked as @external. |
Since v2.0.0 | The value passed to the fields argument of a @requires directive is not a string. |
Since v2.0.0 | The fields argument of a @requires directive is invalid (it has invalid syntax, includes unknown fields, ...). |
Since v2.0.0 | A @requires directive is used on an interface, which is not (yet) supported. |
Since v0.x | A subgraph's schema defines a type with the name mutation, while also specifying a different type name as the root query object. This is not allowed. |
Since v0.x | A subgraph's schema defines a type with the name query, while also specifying a different type name as the root query object. This is not allowed. |
Since v0.x | A subgraph's schema defines a type with the name subscription, while also specifying a different type name as the root query object. This is not allowed. |
Since v2.0.0 | Subgraphs can be merged, but the resulting supergraph API would have queries that cannot be satisfied by those subgraphs. |
Since v2.0.0 | A shareable field return type has mismatched possible runtime types in the subgraphs in which the field is declared. As shared fields must resolve the same way in all subgraphs, this is almost surely a mistake. |
Since v2.0.0 | A built-in or Federation type has an invalid definition in the schema. |
Since v2.0.0 | A type has the same name in different subgraphs, but a different kind. For instance, one definition is an object type but another is an interface.Replaces VALUE_TYPE_KIND_MISMATCH, EXTENSION_OF_WRONG_KIND, ENUM_MISMATCH_TYPE. |
Since v2.0.0 | A Federation 1 schema has a composite type comprised only of unused external fields. Note that this error can only be raised for Federation 1 schema as Federation 2 schema do not allow unused external fields (and errors with code EXTERNAL_UNUSED will be raised in that case). But when Federation 1 schema are automatically migrated to Federation 2 ones, unused external fields are automatically removed, and in rare case this can leave a type empty. If that happens, an error with this code will be raised. |
Since v2.0.0 | The version of Federation in a @link directive on the schema is unknown. |
Since v2.1.0 | The version of @link set on the schema is unknown. |
Since v2.1.0 | Indicates an error due to feature currently unsupported by Federation. |
Since v2.0.0 | Indicates that a feature used in a @link is either unsupported or is used with unsupported options. |
Removed codes
The following error codes have been removed and are no longer generated by the most recent version of the @apollo/gateway library:
| Removed code | Comment |
|---|---|
| As duplicate enum definitions is invalid GraphQL, this will now be an error with code INVALID_GRAPHQL. |
| As duplicate enum values are invalid in GraphQL, this will now be an error with code INVALID_GRAPHQL. |
| As duplicate scalar definitions are invalid in GraphQL, this will now be an error with code INVALID_GRAPHQL. |
| Subgraph definitions for an enum are now merged by composition. |
| As there is no type ownership anymore, there is also no particular limitation as to where a field can be external. |
| This error was thrown by a validation introduced to avoid running into a known runtime bug. Since Federation v2.3, the underlying runtime bug has been addressed and the validation/limitation was no longer necessary and has been removed. |
| Using @external for key fields is now discouraged, unless the field is truly meant to be external. |
| Keys can now use any field from any other subgraph. |
| Each subgraph is now free to declare a key only if it needs it. |
| Each subgraph can declare a key independently of any other subgraph. |
| Every subgraph can have multiple keys, as necessary. |
| Since Federation v2.1.0, the case this error used to cover is now a warning (with code INCONSISTENT_NON_REPEATABLE_DIRECTIVE_ARGUMENTS) instead of an error. |
| @provides can now be used on fields of interface, union, and list types. |
| @provides can now be used on any type. |
| Since Federation v2.1.1, using fields with arguments in a @requires is fully supported. |
| Fields in @requires can now be from any subgraph. |
| As there is no type ownership anymore, there is also no particular limitation as to which subgraph can use a @requires. |
| This error was previously not correctly enforced: the service and entities, if present, were overridden; this is still the case. |
| There is no strong difference between entity and value types in the model (they are just usage patterns), and a type can have keys in one subgraph but not another. |
| Subgraph definitions for a union are now merged by composition. |