Support for progressive overrides described in the Apollo 2.7 release.

[benevolent-donut]

Component(s)

router

Is your feature request related to a problem? Please describe.

@override's all-or-nothing approach makes it challenging to safely migrate a monolith to use Cosmo Router. Once the schema is composed with @override, 100% of traffic immediately routes to the new service with no ability to gradually roll out (1% → 25% → 100%) or validate with a small percentage of production traffic first.

Describe the solution you'd like

Implement Apollo Federation 2.7's progressive override.

type Query {
 user(id: ID!): User @override(from: "monolith", label: "percent(25)")
}

Implementation:

1. Composition: Parse and store label parameter in supergraph metadata
2. Runtime: Router evaluates label per-request and routes accordingly
3. Support built-in percent(X) syntax at minimum

Describe alternatives you've considered

The following approach is the only viable alternative that I've considered.

HTTP middleware that introspects request body:

• Custom @overridePercentage(pct: Int) directive that adds override context to custom HTTP round trippers.
• Parse requests bound for downstreams, determine fields eligible for percentage routing, then route based on the configured percentage.
• Not ideal: requires parsing every request, completely works around cosmo/router's federation implementation.

Additional context

• Apollo introduced this in Federation 2.7 (April 2024)
• Documentation
• Blog post
• Current limitation: graphql-go-tools generates query plans at composition time, would need runtime evaluation

[github-actions]

WunderGraph commits fully to Open Source and we want to make sure that we can help you as fast as possible.
The roadmap is driven by our customers and we have to prioritize issues that are important to them.
You can influence the priority by becoming a customer. Please contact us here.

[jensneuse]

Thanks for the detailed writeup! Before we look into progressive overrides specifically, I wanted to ask — have you looked into Cosmo's feature flags functionality?

Feature flags let you create a "feature subgraph" that replaces a base subgraph on a per-request basis, activated via header (X-Feature-Flag), cookie, or GraphQL extensions. Combined with an upstream proxy or middleware that injects the header on a configurable percentage of requests, you could achieve gradual traffic migration — e.g., 1% of requests get the X-Feature-Flag: users-v2 header and hit the new service, while 99% still go to the monolith.

The key trade-off vs. progressive override: feature flags operate at subgraph granularity (the entire subgraph is replaced), not per-field. So if your migration plan involves moving individual fields incrementally while others stay on the monolith, feature flags wouldn't cover that — you'd need to migrate all the fields you want to override in one go.

Would that approach work for your migration scenario, or do you specifically need per-field percentage-based routing?

[benevolent-donut]

thanks for responding! We looked at feature flags and have found a different use for them.

We have about 180 subgraphs that we would like to migrate. We would like for subgraphs owners to migrate independently, which may also be concurrently with other subgraphs. Feature flags limit our ability to engage in concurrent service migrations because a request can only use one feature flag at a time.

We briefly thought about composite feature flags. Seems like a nightmare to manage and create.

[magnhan]

Seconding the need for this. We are migrating subgraphs with large portions that are only used by old mobile clients which we would prefer not to migrate. Progressive override would by far be the best solution for us