Curiosity question regarding managed federation.
In the docs:
The gateway also knows that your subgraphs are prepared to handle operations against the updated set of schemas. This is because your subgraphs should register their updated schemas as part of their deployment, meaning they’re definitely running by the time the gateway is aware of the configuration change
This makes sense. From the diagram here, here’s how I understand the scenario to act serially:
- Subgraph X re-deploys.
- Subgraph X registers and updates schema.
- Apollo Schema Registry picks up change.
- Apollo Schema Registry updates configuration.
- Polling Gateway picks up change in configuration.
Here’s my question:
What happens in the time between 2-3 vis-a-vis the Gateway for breaking, backwards-incompatible changes on the actual Subgraph X service layer business logic?
An example (potential?) high-latency race condition situation:
I remove a column from the database. Migrations run with deployment. That field gets removed from the Subgraph X schema. But if a query for removed field gets through the Gateway (before new schema is picked up on #5), the Subgraph X service should be up and running - would this fail at the service/resolver layer?
The way I understand it - and please correct me otherwise! - the way around this would be to have Pub/Sub on the registry back to the Gateway once new Subgraph X schema is registered rather than the Gateway polling the registry. Is this wrong?
…and in a moment of self-awareness - this example is contrived and I understand the point of Managed Federation is that it solves this type of situation that happens every time when deploying manually without a manager - just want to understand if all the risk is gone (or just most)