Composition hints
When you successfully compose the schemas provided by your subgraphs into a supergraph schema, the composition process can flag potential improvements or hints. Hints are violations of the GraphOS schema linter's composition rules. You can review them on the Checks page in GraphOS Studio or via the Rover CLI.
Composition hints only appear in GraphOS Studio and via the rover subgraph check command for graphs on federation version 2.4 or later. You can update a graph's version from its Settings page in GraphOS Studio.
The rover subgraph check command outputs rule violations with the severity levels you've configured for your graph variant. The rover supergraph compose command outputs rule violations for all local subgraph schemas.
See below for a list of composition rules categorized by rule type. The heading for each rule is the code that GraphOS returns for the rule violation. Refer to the rules reference page for a comprehensive list of linter rules.
Inconsistent elements
These rules identity inconsistencies in fields, types, arguments, etc across subgraphs. Such inconsistencies can disrupt or even break composition.
Compatibility
In some cases, inconsistency rules also indicate the compatibility of checked types. Two types are compatible if one is a non-nullable version, a list version, a subtype, or a combination of any of these of the other.
For example, the price fields in the example subgraphs below are inconsistent and incompatible because they use completely different types (Float vs String):
Subgraph A
type Product {id: ID!name: Stringprice: Float}
Subgraph B
type Product {id: ID!name: Stringprice: String}
These price fields in the example subgraphs below are inconsistent but compatible since both use Floats, but one is nullable and the other is the non-nullable list of Floats.
Subgraph A
type Product {id: ID!name: Stringprice: Float}
Subgraph B
type Product {id: ID!name: Stringprice: [Float]!}
What it does
Checks that an argument of a field or directive definition is present in all subgraphs.Rationale
The supergraph schema only includes arguments that are exactly the same for all subgraphs that define its field or directive. Learn more.Examples
The following example violates the rule:
❌ Subgraph A
type Product {id: ID!name: Stringprice(currency: Currency): Float}
❌ Subgraph B
type Product {id: ID!name: Stringprice(currency: Currency, taxIncluded: Boolean): Float}
Use instead:
✅ Subgraph A
type Product {id: ID!name: Stringprice(currency: Currency, taxIncluded: Boolean): Float}
✅ Subgraph B
type Product {id: ID!name: Stringprice(currency: Currency, taxIncluded: Boolean): Float}
What it does
Checks that arguments (of a field, input field, or directive definition) have the exact same types in all subgraphs. This warning/error indicates the argument types are compatible but inconsistent.Rationale
The supergraph schema only includes arguments that are exactly the same for all subgraphs that define its field or directive. Learn more.Examples
Because subgraph A's price field expects a non-nullable Currency argument type and subgraph B allows a nullable Currency argument type, the following example violates the rule:
❌ Subgraph A
type Product {id: ID!name: Stringprice(currency: Currency!): Float}enum Currency {USDEURGBPJPYAUDCAD}
❌ Subgraph B
type Product {id: ID!name: Stringprice(currency: Currency): Float}enum Currency {USDEURGBPJPYAUDCAD}
Use instead:
✅ Subgraph A
type Product {id: ID!name: Stringprice(currency: Currency!): Float}enum Currency {USDEURGBPJPYAUDCAD}
✅ Subgraph B
type Product {id: ID!name: Stringprice(currency: Currency!): Float}enum Currency {USDEURGBPJPYAUDCAD}
What it does
Checks that fields have the exact same types in all subgraphs. This warning/error indicates the field types are compatible but inconsistent.Rationale
Inconsistent types can lead to discrepancies in the way data is retrieved and processed, resulting in unexpected client behavior.Examples
The following example violates the rule:
❌ Subgraph A
type Product {id: ID!name: Stringprice: Money}type Money {amount: Float!currency: Currency!}enum Currency {USDEURGBPJPYAUDCAD}
❌ Subgraph B
type Product {id: ID!name: Stringprice: Money!}type Money {amount: Float!currency: Currency!}enum Currency {USDEURGBPJPYAUDCAD}
Use instead:
✅ Subgraph A
type Product {id: ID!name: Stringprice: Money!}type Money {amount: Float!currency: Currency!}enum Currency {USDEURGBPJPYAUDCAD}
✅ Subgraph B
type Product {id: ID!name: Stringprice: Money!}type Money {amount: Float!currency: Currency!}enum Currency {USDEURGBPJPYAUDCAD}
What it does
Checks that argument definitions (of a field, input field, or directive definition) consistently include—or consistently don't include—a default value in all subgraphs that define the argument.Rationale
Inconsistent defaults can lead to discrepancies in the way data is retrieved and processed, resulting in unexpected client behavior.Examples
The following example violates the rule:
❌ Subgraph A
type Product {id: ID!name: Stringweight(kg: Float = 1.0): Float}
❌ Subgraph B
type Product {id: ID!name: Stringweight(kg: Float): Float}
Use instead:
✅ Subgraph A
type Product {id: ID!name: Stringweight(kg: Float = 1.0): Float}
✅ Subgraph B
type Product {id: ID!name: Stringweight(kg: Float = 1.0): Float}
What it does
Checks that a type's description is consistent across subgraphs.Rationale
Inconsistent type descriptions can lead to inconsistent expectations around type values resulting in unexpected client behavior.Examples
The following example violates the rule:
❌ Subgraph A
"""A type representing a product."""type Product {id: ID!name: String}
❌ Subgraph B
"""An object representing a product."""type Product {id: ID!name: String}
Use instead:
✅ Subgraph A
"""A type representing a product."""type Product {id: ID!name: String}
✅ Subgraph B
"""A type representing a product."""type Product {id: ID!name: String}
What it does
Checks that an object is consistently declared as an entity (has a@key) in all subgraphs in which the object is defined.Rationale
If an object is only declared as an entity in some subgraphs, the federated schema won't have complete information about that entity.Examples
The following example violates the rule:
❌ Subgraph A
type Product @key(fields: "id") {id: ID!name: String}
❌ Subgraph B
type Product {id: ID!stock: Int}
Use instead:
✅ Subgraph A
type Product @key(fields: "id") {id: ID!name: String}
✅ Subgraph B
type Product @key(fields: "id") {id: ID!stock: Int}
What it does
Checks that values of an input enum type are consistently defined in all subgraphs that declare the enum.Rationale
When a value of an enum that is only used as an input type is defined in only some of the subgraphs that declare the enum, inconsistent values won't be merged into the supergraph. Learn more.Examples
The following example violates the rule:
❌ Subgraph A
enum ProductStatus {AVAILABLESOLD_OUTBACK_ORDER}input ProductInput {name: String!status: ProductStatus!}
❌ Subgraph B
enum ProductStatus {AVAILABLESOLD_OUT}input ProductInput {name: String!status: ProductStatus!}
Use instead:
✅ Subgraph A
enum ProductStatus {AVAILABLESOLD_OUTBACK_ORDER}input ProductInput {name: String!status: ProductStatus!}
✅ Subgraph B
enum ProductStatus {AVAILABLESOLD_OUTBACK_ORDER}input ProductInput {name: String!status: ProductStatus!}
What it does
Checks that values of an output enum type are consistently defined in all subgraphs that declare the enum.Rationale
When values of an output or unused enum type definition are inconsistent, all values are merged into the supergraph. Regardless, it can be helpful to set expectations by including all possible values in all subgraphs defining the enum. Learn more.Examples
The following example violates the rule:
❌ Subgraph A
enum OrderStatus {CREATEDPROCESSINGCOMPLETED}type Order {name: String!status: OrderStatus!}
❌ Subgraph B
enum OrderStatus {CREATEDCOMPLETED}type Order {name: String!status: OrderStatus!}
Use instead:
✅ Subgraph A
enum OrderStatus {CREATEDPROCESSINGCOMPLETED}type Order {name: String!status: OrderStatus!}
✅ Subgraph B
enum OrderStatus {CREATEDPROCESSINGCOMPLETED}type Order {name: String!status: OrderStatus!}
What it does
Checks that an executable directive definition is declared with consistent locations across all subgraphs.Rationale
An executable directive is composed into the supergraph schema only when it is defined identically in all subgraphs. Learn more.Examples
The following example violates the rule:
❌ Subgraph A
directive @log(message: String!) on QUERY
❌ Subgraph B
directive @log(message: String!) on FIELD
Use instead:
✅ Subgraph A
directive @log(message: String!) on QUERY | FIELD
✅ Subgraph B
directive @log(message: String!) on QUERY | FIELD
What it does
Checks that an executable directive definition is declared in all subgraphs.Rationale
An executable directive is composed into the supergraph schema only if it's defined in all subgraphs. Learn more.Examples
The following example violates the rule:
❌ Subgraph A
directive @modify(field: String!) on FIELD
❌ Subgraph B
# 🦗🦗🦗
Use instead:
✅ Subgraph A
directive @modify(field: String!) on FIELD
✅ Subgraph B
directive @modify(field: String!) on FIELD
What it does
Checks that an executable directive definition is markedrepeatable in all subgraphs that define it.Rationale
Unless an executable directive is defined asrepeatable in all subgraphs, it won't be repeatable in the supergraph.Examples
The following example violates the rule:
❌ Subgraph A
directive @validateLength(max: Int!) repeatable on FIELD
❌ Subgraph B
directive @validateLength(max: Int!) on FIELD
Use instead:
✅ Subgraph A
directive @validateLength(max: Int!) repeatable on FIELD
✅ Subgraph B
directive @validateLength(max: Int!) repeatable on FIELD
What it does
Checks that a field of an input object definition is defined in all the subgraphs that declare the input object.Rationale
The supergraph schema includes only the input object fields that all subgraphs define for the object. Learn more.Examples
The following example violates the rule:
❌ Subgraph A
input ProductInput {name: Stringprice: Float}input OrderInput {product: ProductInput}
❌ Subgraph B
input ProductInput {name: String}input OrderInput {product: ProductInput}
Use instead:
✅ Subgraph A
input ProductInput {name: Stringprice: Float}input OrderInput {product: ProductInput}
✅ Subgraph B
input ProductInput {name: Stringprice: Float}input OrderInput {product: ProductInput}
What it does
Checks that a field of an interface value type (has no@key in any subgraph) is defined in all the subgraphs that declare the type.Rationale
If different subgraphs contribute different fields to an interface type, any object types that implement that interface must define all contributed fields from all subgraphs. Otherwise, composition fails. Learn more.Examples
The following example violates the rule:
❌ Subgraph A
interface Product {id: ID!name: Stringcost: Float}type DigitalProduct implements Product {id: ID!name: Stringcost: Floatsize: Int}
❌ Subgraph B
interface Product {id: ID!name: String# cost is not defined in the interface}type PhysicalProduct implements Product {id: ID!name: Stringcost: Floatweight: Float}
Use instead:
✅ Subgraph A
interface Product {id: ID!name: Stringcost: Float}type DigitalProduct implements Product {id: ID!name: Stringcost: Floatsize: Int}
✅ Subgraph B
interface Product {id: ID!name: Stringcost: Float}type PhysicalProduct implements Product {id: ID!name: Stringcost: Floatweight: Float}
What it does
Checks if a non-repeatable directive is applied to a schema element across different subgraphs with differing arguments.Rationale
Inconsistent directive argument usage can lead to misunderstandings and potential issues in client applications.Examples
The following example violates the rule:
❌ Subgraph A
type Product {id: ID!name: String}type Query {allProducts: [Product] @customDirective(orderBy: "name")}
❌ Subgraph B
type Product {id: ID!name: String}type Query {allProducts: [Product] @customDirective(orderBy: "price")}
Use instead:
✅ Subgraph A
type Product {id: ID!name: String}type Query {allProducts: [Product] @customDirective(orderBy: "name")}
✅ Subgraph B
type Product {id: ID!name: String}type Query {allProducts: [Product] @customDirective(orderBy: "name")}
What it does
Checks that object value types (has no@key in any subgraph) declare the same fields in all subgraphs that declare the type.Rationale
When an object value type includes differing fields across subgraphs, the supergraph schema includes the union of all fields. Depending on which subgraph executes the query, omitted fields may be unresolvable. You can include the same types as shown below or check out Solutions for unresolvable fields.Examples
The following example violates the rule:
❌ Subgraph A
type Product {id: ID! @shareablename: String @shareableprice: Float}
❌ Subgraph B
type Product {id: ID! @shareablename: String @shareable}
Use instead:
✅ Subgraph A
type Product @shareable {id: ID!name: Stringprice: Float}
✅ Subgraph B
type Product @shareable {id: ID!name: Stringprice: Float}
What it does
Checks that a@shareable field returns consistent sets of runtime types in all subgraphs in which it's defined.Rationale
Each subgraph's resolver for a@shareable field should behave identically. Otherwise, requests might return inconsistent results depending on which subgraph resolves the field. Learn more.Examples
The following example violates the rule:
❌ Subgraph A
type Product {id: ID!name: Stringdetails: Details @shareable}type Details {size: String}
❌ Subgraph B
type Product {id: ID!name: Stringdetails: Details @shareable}type Details {weight: Float}
Use instead:
✅ Subgraph A
type Product {id: ID!name: Stringdetails: Details @shareable}type Details {size: String}
✅ Subgraph B
type Product {id: ID!name: Stringdetails: Details @shareable}type Details {size: String}
What it does
Checks that a type system directive definition is declared with consistent locations across subgraphs.Rationale
To ensure consistent expectations, it's best that all definitions declare the same locations. Learn more.Examples
The following example violates the rule:
❌ Subgraph A
directive @customDirective(message: String!) on OBJECT | FIELD_DEFINITION
❌ Subgraph B
directive @customDirective(message: String!) on FIELD_DEFINITION
Use instead:
✅ Subgraph A
directive @customDirective(message: String!) on OBJECT | FIELD_DEFINITION
✅ Subgraph B
directive @customDirective(message: String!) on OBJECT | FIELD_DEFINITION
What it does
Checks that a type system directive definition is markedrepeatable in all subgraphs that declare the directive and will be repeatable in the supergraph.Rationale
To ensure consistent expectations, directives should have consistent definitions across subgraphs, including whether they arerepeatable. Learn more.Examples
The following example violates the rule:
❌ Subgraph A
directive @customDirective on OBJECT
❌ Subgraph B
directive @customDirective repeatable on OBJECT
Use instead:
✅ Subgraph A
directive @customDirective repeatable on OBJECT
✅ Subgraph B
directive @customDirective repeatable on OBJECT
What it does
Checks that a member of a union definition is defined in all subgraphs that declare the union.Rationale
When a union definition has inconsistent members, the supergraph schema includes all members in the union definition. Nevertheless, to ensure consistent expectations, it's best that all union definitions declare the same members across subgraphs. Learn more.Examples
The following example violates the rule:
❌ Subgraph A
type Product {id: ID!name: String}type Service {id: ID!description: String}union SearchResult = Product | Service
❌ Subgraph B
type Product {id: ID!name: String}union SearchResult = Product
Use instead:
✅ Subgraph A
type Product {id: ID!name: String}type Service {id: ID!description: String}union SearchResult = Product | Service
✅ Subgraph B
type Product {id: ID!name: String}type Service {id: ID!description: String}union SearchResult = Product | Service
Overridden and unused elements
Rationale
If a field with the@override directive no longer exists in a source subgraph, the directive can be safely removed.Examples
The following example violates the rule:
❌ Subgraph A
type Product @key(fields: "id") {id: ID!inStock: Boolean! @override(from: "Subgraph B")}
❌ Subgraph B
type Product @key(fields: "id") {id: ID!name: String!}
Use instead:
✅ Subgraph A
type Product @key(fields: "id") {id: ID!inStock: Boolean!}
✅ Subgraph B
type Product @key(fields: "id") {id: ID!name: String!}
What it does
Checks if a field has been overridden by another subgraph.Rationale
You should consider removing overriden fields to avoid confusion.Examples
The following example violates the rule:
❌ Subgraph A
type Product @key(fields: "id") {id: ID!inStock: Boolean! @override(from: "Subgraph B")}
❌ Subgraph B
type Product @key(fields: "id") {id: ID!name: String!inStock: Boolean!}
Use instead:
✅ Subgraph A
type Product @key(fields: "id") {id: ID!name: String!inStock: Boolean!}
✅ Subgraph B
type Product @key(fields: "id") {id: ID!name: String!}
What it does
Checks if an enum type is defined but no field or argument in any erences it.Rationale
If the enum is defined, it should be used or removed.Examples
The following example violates the rule:
❌ Subgraph A
enum ProductStatus {AVAILABLESOLD_OUT}type Product {id: ID!name: String}
❌ Subgraph B
type Order {id: ID!product: Productstatus: String}
Use instead:
✅ Subgraph A
enum ProductStatus {AVAILABLESOLD_OUT}type Product {id: ID!name: Stringstatus: ProductStatus}
✅ Subgraph B
type Order {id: ID!product: Productstatus: ProductStatus}
Directives
What it does
Checks for issues when composing custom directives.What it does
Checks if a non-repeatable directive has been applied to the same schema element in different subgraphs with different arguments. Learn more.Rationale
Arguments should be consistent across a non-repeatable directive's usage. If arguments differ, it may be a sign that subgraph owners need to communicate about the directive's usage. If the arguments need to differ, consider using a repeatable directive.Examples
The following example violates the rule:
❌ Subgraph A
type Product {id: ID!name: String}type Query {products: [Product] @customDirective(orderBy: ["name"])}
❌ Subgraph B
type Product {id: ID!name: String}type Query {products: [Product] @customDirective(orderBy: ["price"])}
Use instead:
✅ Subgraph A
type Product {id: ID!name: String}type Query {products: [Product] @customDirective(orderBy: ["name", "price"])}
✅ Subgraph B
type Product {id: ID!name: String}type Query {products: [Product] @customDirective(orderBy: ["name", "price"])}
Rationale
Directives must only be used in the locations they are declared to belong in. If the same executable directive is defined with different locations in different subgraphs, it may be a sign that subgraph owners need to communicate about the directive's usage.Examples
The following example violates the rule:
❌ Subgraph A
directive @log(message: String!) on QUERY
❌ Subgraph B
directive @log(message: String!) on FIELD
Use instead:
✅ Subgraph A
directive @log(message: String!) on QUERY | FIELD
✅ Subgraph B
directive @log(message: String!) on QUERY | FIELD
Rationale
The@override directive indicates that an object field is now resolved by a different subgraph. The directive can't work unless you specify an existing subgraph to resolve the field from.Examples
The following example violates the rule:
❌ Subgraph A
type Product @key(fields: "id") {id: ID!inStock: Boolean! @override(from: "Subgraph B")}
❌ Subgraph B
# Subgraph B doesn't exist
Use instead:
✅ Subgraph A
type Product @key(fields: "id") {id: ID!inStock: Boolean! @override(from: "Subgraph B")}
✅ Subgraph B
type Product @key(fields: "id") {id: ID!inStock: Boolean!}