Gateway does not trigger correct resolvers when subgraphs extend and reuse shared types
abc-moviestarplanet opened this issue · comments
Given the following 2 graphql subgraphs:
Subgraph 1:
extend type Query {
users: PageOfUser
}
type PageOfUser {
nodes: [User]
}
type User @key(fields: "id") {
id: ID!
name: String
}
Subgraph 2:
extend type User @key(fields: "id") {
id: ID! @external
friends: PageOfUser # <-- this is problematic
}
type PageOfUser {
nodes: [User]
}
Subgraph 2 has a resolver for friends
which always returns some data.
If I run the following query against the Gateway:
query {
users {
nodes {
id
friends {
nodes {
id
}
}
}
}
}
The response is:
{
"data": {
"users": {
"nodes": [
{
"id": "0",
"friends": null // should not be null
},
{
"id": "1",
"friends": null // should not be null
}
]
}
}
}
And the friends resolver never triggers.
I can get the data for friends correctly if I manually query subgraph 2 directly like this:
query {
_entities(representations: [{ __typename:"User", id: 1 }]) {
...on User {
id
friends {
nodes {
id
}
}
}
}
}
So from what I can understand, the Gateway is not requesting the "friends" data from Subgraph 2.
Now if in Subgraph 2 I rename the type PageOfUser
to PageOfFriends
(a name that is different from that defined in Subgraph 1) then it works fine through the Gateway.
According to this https://www.apollographql.com/docs/federation/v1/value-types/, it is fine for the subgraphs to define the same types multiple times, as long as they are exactly identical.
Is this a bug or a misuse of federation?
Sample to reproduce:
https://github.com/abc-moviestarplanet/GatewayResolverIssue/tree/main
Thanks for reporting!
Can you provide steps to reproduce? We often need a reproducible example, e.g. some code that allows someone else to recreate your problem by just copying and pasting it. If it involves more than a couple of different file, create a new repository on GitHub and add a link to that.
Here is a repository with steps to reproduce: https://github.com/abc-moviestarplanet/GatewayResolverIssue/tree/main
@marco-ippolito could you take a look?
probably related to #22