Component(s)
router
Is your feature request related to a problem? Please describe.
Today, header rules under headers.subgraphs are matched by exact subgraph name only. This creates a gap for feature subgraph workflows.
A feature subgraph is composed under its own name (e.g. products-feature-pr-123) rather than the base subgraph name (products). Any per-subgraph header rules configured for products do not apply to its feature variants. Only headers.all rules carry over automatically.
There are two workarounds today:
-
Promote rules to headers.all. This covers feature subgraphs, but the rule applies to every subgraph in the graph. For teams using per-subgraph header lists as an explicit allow-list — to avoid leaking credentials or keep cache-key surfaces tight — this is too broad.
-
Add a separate headers.subgraphs.<feature-name> block for each feature subgraph. This is precise, but requires knowing each feature subgraph name in advance and editing the router config + triggering a redeploy for each one. In workflows where feature subgraphs are short-lived and numerous (per-branch or per-PR), this means a router redeploy for what should be a localized, ephemeral change.
Describe the solution you'd like
A way to target subgraphs more flexibly in the header rules engine — for example, via regex selectors or named groups — so a single rule can cover a base subgraph and its feature variants without listing each name explicitly.
Two proof-of-concept implementations were submitted as draft PRs if they're useful as reference:
- #2868 — regex selectors via
headers.subgraph_patterns
- #2869 — named groups via
headers.groups (supports explicit lists, regex, or both)
I personally think the headers.groups pattern is more interesting/useful, but I am not super familiar with the internal configuration shape / roadmap of the config file.
Happy to discuss API shape or provide more context on our use case.
Describe alternatives you've considered
No response
Additional context
No response
Component(s)
router
Is your feature request related to a problem? Please describe.
Today, header rules under
headers.subgraphsare matched by exact subgraph name only. This creates a gap for feature subgraph workflows.A feature subgraph is composed under its own name (e.g.
products-feature-pr-123) rather than the base subgraph name (products). Any per-subgraph header rules configured forproductsdo not apply to its feature variants. Onlyheaders.allrules carry over automatically.There are two workarounds today:
Promote rules to
headers.all. This covers feature subgraphs, but the rule applies to every subgraph in the graph. For teams using per-subgraph header lists as an explicit allow-list — to avoid leaking credentials or keep cache-key surfaces tight — this is too broad.Add a separate
headers.subgraphs.<feature-name>block for each feature subgraph. This is precise, but requires knowing each feature subgraph name in advance and editing the router config + triggering a redeploy for each one. In workflows where feature subgraphs are short-lived and numerous (per-branch or per-PR), this means a router redeploy for what should be a localized, ephemeral change.Describe the solution you'd like
A way to target subgraphs more flexibly in the header rules engine — for example, via regex selectors or named groups — so a single rule can cover a base subgraph and its feature variants without listing each name explicitly.
Two proof-of-concept implementations were submitted as draft PRs if they're useful as reference:
headers.subgraph_patternsheaders.groups(supports explicit lists, regex, or both)I personally think the
headers.groupspattern is more interesting/useful, but I am not super familiar with the internal configuration shape / roadmap of the config file.Happy to discuss API shape or provide more context on our use case.
Describe alternatives you've considered
No response
Additional context
No response