You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When using schema stitching, if a field a: A is included in a query with selections a { x y z }, then a is incorrectly resolved to null if x, y, z are all extensions to the stitched schema, and resolved through delegation to a different schema than the subschema that resolves a.
To Reproduce Steps to reproduce the behavior:
Create two subschemas A and B, where A contains an object type aNamespace
Stitch the two schemas together, and add an extensions that adds a field to aNamespace which resolves to a value in schema B
Perform a query which includes aNamespace, and where it's selections consist of a single instance of the extension field (delegated to B
Notice that the response contains aNamespace: null, when instead it should contain aNamespace: { extensionField: <some value> }
Expected behavior
If there are selections on a non-scalar field in the query, then it should be possible to resolve those selections, even if none of the selections happen to be resolved on the same subschema that resolved the field.
This can be worked around by adding a field to the selection set that is resolved by the same subschema that resolves the field. For example in the reproduction, the test executes stitched query with dummy field passes, but the test executes stitched query without dummy field fails.
An automated way of doing this (also transparent to the user of the API) is to use the following transform, which adds __typename to every selection set in the query:
Issue workflow progress
Progress of the issue based on the
Contributor Workflow
Describe the bug
When using schema stitching, if a field
a: A
is included in a query with selectionsa { x y z }
, thena
is incorrectly resolved tonull
ifx
,y
,z
are all extensions to the stitched schema, and resolved through delegation to a different schema than the subschema that resolvesa
.To Reproduce Steps to reproduce the behavior:
A
andB
, whereA
contains an object typeaNamespace
aNamespace
which resolves to a value in schemaB
aNamespace
, and where it's selections consist of a single instance of the extension field (delegated toB
aNamespace: null
, when instead it should containaNamespace: { extensionField: <some value> }
Expected behavior
If there are selections on a non-scalar field in the query, then it should be possible to resolve those selections, even if none of the selections happen to be resolved on the same subschema that resolved the field.
Environment:
@graphql-tools/stitch
: c30c1c7 (9.0.3)Additional context
This can be worked around by adding a field to the selection set that is resolved by the same subschema that resolves the field. For example in the reproduction, the test
executes stitched query with dummy field
passes, but the testexecutes stitched query without dummy field
fails.An automated way of doing this (also transparent to the user of the API) is to use the following transform, which adds
__typename
to every selection set in the query:See a reproduction here in the form of a failing test: #5741
The text was updated successfully, but these errors were encountered: