Apollo Federation @key directive: missing key selection priority constraint

Entity key resolution ambiguity

Apollo Federation allows entities to define multiple @key directives, each declaring a different set of fields that can uniquely identify an entity across subgraphs. The gateway's query planner chooses which key to use based on the fields requested in the incoming operation, but the selection algorithm lacks a documented priority order or configurable constraint.

Operational impact

Without a guaranteed selection order, the same query can produce different query plans across gateway versions or even between planning cycles. This non-determinism complicates performance tuning, as subgraph authors cannot enforce the use of a more efficient key—such as one backed by a database index—over a less optimal alternative. Workarounds like restricting entities to a single key or adding @provides/@requires directives increase schema complexity without addressing the root constraint gap.

Can the Federation specification define a deterministic key selection priority? Is there a mechanism for subgraph authors to declare a preferred key for a given query pattern? Will future gateway releases expose a configuration option to control this behavior?