Hi Derek,
Thanks for the reply. I setup a demo of the bug in GitHub - yuhanz/bug-demo · GitHub
Install the dependencies with npm install --force , and start the app with sh start.sh. The input form is available at: http://localhost:4000/federation/
The app has 1 subgraph, which is based on schemas/subgraph.graphqls converted to schemas/supergraph2.sdl . I used src/MockGraphqlDataSource.js to emulate a subgraph backend where it responds json without typename when it is not in the query and add typename in the response when it appears in the query.
This query will demonstrate the bug:
fragment optionFields on IOption {
id
... on ColorOption {
primaryRGB
}
}
{
style(styleId: "401822600") {
options {
colors { ...optionFields }
}
}
}
The result isn’t rendered correctly with the RGB related field:
{
"data": {
"style": {
"options": {
"colors": [
{
"id": "1"
},
{
"id": "2"
}
]
}
}
}
}
The query has to include __typename in fragment to become a working query:
fragment optionFields on IOption {
id
... on ColorOption {
primaryRGB
}
}
{
style(styleId: "401822600") {
options {
colors {
__typename
...optionFields }
}
}
}
That gives the expected result:
{
"data": {
"style": {
"options": {
"colors": [
{
"__typename": "ColorOption",
"id": "1",
"primaryRGB": [
255,
255,
255
]
},
{
"__typename": "ColorOption",
"id": "2",
"primaryRGB": [
9,
9,
9
]
}
]
}
}
}
}
Meanwhile, inline fragment always works, as it knows to include __typename automatically:
{
style(styleId: "401822600") {
options {
colors {
... on ColorOption {
primaryRGB
} }
}
}
}
Quite unfortunately, I wasn’t able to identify at which combination of earlier versions of dependencies, fragment still worked. (It could be a combination of “@apollo/gateway” and “graphql”). But it used to be smart enough to know when to include __typename automatically for fragment queries.
It seems a bug. Or maybe it has to do with my project setup / config parameters / dependency version? Could you guide, please?
Thank you.
Yuhan Zhang
