-
Notifications
You must be signed in to change notification settings - Fork 23
Description
Using the example, the following query works
query {
findProduct {
id
name
}
}{
"data": {
"findProduct": {
"id": "123",
"name": "name from transformed service"
}
}
}however this query with an alias does not work
query {
findProduct {
id
aliasedName: name
}
}{
"errors": [
{
"message": "Cannot return null for non-nullable field Product.name.",
"path": [
"_entities",
0,
"aliasedName"
],
"extensions": {
"code": "INTERNAL_SERVER_ERROR",
"serviceName": "transformed",
"query": "query($representations:[_Any!]!){_entities(representations:$representations){...on Product{aliasedName:name}}}",
"variables": {
"representations": [
{
"__typename": "Product",
"id": "123"
}
]
},
}
}
],
"data": null
}I've dug into this a fair amount, and as best as I can tell, this comes because in the course of satisfying this query, the "transformed" data source is queried "twice". The federation server slices up the query and sends the entity query to the transformed subgraph
query($representations: [_Any!]!) {
_entities(representations: $representations) {
... on Product {
aliasedName: name
}
}
}(This query has the alias, as one would expect). This query then gets handled by the schema that transformSchemaFederation creates. The relevant parts of the query (including aliases) get sent to resolveReference, which then executes them against the subgraph server. The response from delegateToSchema is
{
"aliasedName": "name from transformed service"
}This is where the error arises from, because the query that the federation server made (see above) fulfilled by applying it against the subschema. When the subschema returns with the aliased field names, the query made against it fails since the shape of the data doesn't match the expected shape (missing name).
I think to do this "right" this library needs to transform the query and data instead of using deletateToSchema and effectively "double querying"? But maybe there's an easier fix I'm missing?