We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
@requires
Utilizing @requires on root query fields results in a broken query plan that does not return the required fields.
Code sandbox appears broken?
The code sandbox appears to be broken, so unable to share a working example at the moment.
As a minimum reproducible example, given subgraphs:
1:
extend schema @link(url: "https://specs.apollo.dev/federation/v2.5", import: ["@key"]) type Query @key(fields: "__typename") { b: B! } type B { id: ID! }
and subgraph 2:
extend schema @link( url: "https://specs.apollo.dev/federation/v2.5" import: ["@key", "@inaccessible", "@requires", "@external"] ) type Query @key(fields: "__typename") { a: A! @requires(fields: "b {id}") b: B! @external } type A @key(fields: "id") { id: ID! a: String } type B @external { id: ID! }
It will successfully compose. However running the following operation:
query { a { a } }
Which should in theory require:
b {id}, but does not; the query plan for this results in:
b {id}
QueryPlan { Sequence { Fetch(service: "2") { { a { a } } }, Flatten(path: "") { Fetch(service: "1") { { ... on Query { b { id } } } }, }, }, }
Which basically does the inverse of what is required.
This ideally should either be A) allowed and properly handled or B) fail composition as the behavior is not supported/is broken.
The text was updated successfully, but these errors were encountered:
No branches or pull requests
Issue Description
Utilizing
@requires
on root query fields results in a broken query plan that does not return the required fields.Link to Reproduction
Code sandbox appears broken?
Reproduction Steps
The code sandbox appears to be broken, so unable to share a working example at the moment.
As a minimum reproducible example, given subgraphs:
1:
and subgraph 2:
It will successfully compose. However running the following operation:
Which should in theory require:
b {id}
, but does not; the query plan for this results in:Which basically does the inverse of what is required.
This ideally should either be A) allowed and properly handled or B) fail composition as the behavior is not supported/is broken.
The text was updated successfully, but these errors were encountered: