Composition in the Schema Registry

When you publish a subgraph, the registry will attempt to compose it with all the other subgraphs published in the branch.

If composition succeeds, the result is a new federated graph schema. The router picks up that schema, and it becomes the new public facing API for the federated graph.

If composition fails, the federated graph is not updated, it keeps running with the previously working federated schema. The branch is now in a state where the subgraphs do not compose. You will see the composition errors and hints on how to fix them on each new publish and check invocation, until the subgraphs schemas compose together again without error.

Publishing still succeeds even when that results in composition errors and a branch that is in a failing state, because valid migration workflows depend on that behaviour.

For example, assume you want to move a type from subgraph A to subgraph B. There is a zero downtime, non-breaking migration path that involves the subgraphs on the branch not composing during the migration:

  1. Add the type to subgraph B.
  2. Publish and deploy subgraph B.
  3. Delete the type from subgraph A.
  4. Publish and deploy subgraph A.

In the time between (2.) and (4.), the branch will fail to compose because the type is not owned by a single subgraph, but subgraph A will still serve queries for the type.

Was this page helpful?