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
1. The issue provides a reproduction available on Github, Stackblitz or CodeSandbox
Make sure to fork this template and run yarn generate in the terminal.
Please make sure the GraphQL Tools package versions under package.json matches yours.
2. A failing test has been provided
3. A local solution has been provided
4. A pull request is pending review
Describe the bug
When multiple copies of @graphql-tools/delegate are available in a workspace (eg: because stitch and wrap depend on different versions), creating symbols with Symbol() can lead to bugs when one version of delegate sets an object property using its version of the symbol which the other delegate instance will not be able to access.
The problem occurs in executeDelegationStage, when the selectionSet fields returned by the stitched subschema are merged with the existing fields. Due to multiple versions of delegate, each with it's own instance of OBJECT_SUBSCHEMA_SYMBOL, the subschema information associated with symbols set in annotateExternalObject() by one delegate instance cannot be accessed by executeDelegationStage() within another instance.
Using Symbol.for() fixes this: as long as both versions of delegate use the same string description, they will refer to the same symbol.
Progress of the issue based on the Contributor Workflow
Describe the bug
When multiple copies of
@graphql-tools/delegate
are available in a workspace (eg: becausestitch
andwrap
depend on different versions), creating symbols withSymbol()
can lead to bugs when one version ofdelegate
sets an object property using its version of the symbol which the otherdelegate
instance will not be able to access.The problem occurs in
executeDelegationStage
, when the selectionSet fields returned by the stitched subschema are merged with the existing fields. Due to multiple versions ofdelegate
, each with it's own instance ofOBJECT_SUBSCHEMA_SYMBOL
, the subschema information associated with symbols set inannotateExternalObject()
by onedelegate
instance cannot be accessed byexecuteDelegationStage()
within another instance.Using
Symbol.for()
fixes this: as long as both versions of delegate use the same string description, they will refer to the same symbol.To Reproduce
Steps to reproduce the behavior:
Our dependency tree:
Expected behavior
Environment:
@graphql-tools/...
:Additional context
The text was updated successfully, but these errors were encountered: