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
Specifying returnData breaks resolver merging of @graphql-tools/delegate, causing errors like enum cannot represent value and silently ignoring actual errors.
Steps to reproduce
Repo here if you want to just run it (see the readme), but I will describe the steps in detail as well.
Setup
I've chosen the gRPC handler because it allows me to define enums with numeric values (which will become important later) but also because that's what I'm using when encountering this bug in the real world. The service definition is rather simple; just an enum and and object type with a value of that enum. The implementation is trivial with an input argument throw to conditionally return an error instead.
However the problem occurs when we introduce some additions to the schema. I'm going to add a new resolver which meshes the existing resolver to return a value directly. I should now be able to make a very similar query as above.
Input
{additionalTypeDefs: ` extend type Query { getValue: Value } `,additionalResolvers: [{type: "Query",field: "getValue",targetSource: "Source",targetMethod: "getObject",returnData: "value",args: {"input.throw": "{args.input.throw}"},},],}
I've managed to achieve option 1 via patch-package in the reproduction repo linked above. It doesn't get error locations/paths correct so I'm wondering if option 2 would be more robust, but I haven't tried it yet. Note that I also had to patch merger-stitching to bypass mergeSingleSchema() as it wasn't setting stitchingInfo which is required to resolve external values.
The text was updated successfully, but these errors were encountered:
Long overdue followup to ardatan/graphql-tools#2214
TLDR
Specifying
returnData
breaks resolver merging of @graphql-tools/delegate, causing errors likeenum cannot represent value
and silently ignoring actual errors.Steps to reproduce
Repo here if you want to just run it (see the readme), but I will describe the steps in detail as well.
Setup
I've chosen the gRPC handler because it allows me to define enums with numeric values (which will become important later) but also because that's what I'm using when encountering this bug in the real world. The service definition is rather simple; just an enum and and object type with a value of that enum. The implementation is trivial with an input argument
throw
to conditionally return an error instead.The mesh converts this to GraphQL and allows calling the resolver as expected.
However the problem occurs when we introduce some additions to the schema. I'm going to add a new resolver which meshes the existing resolver to return a value directly. I should now be able to make a very similar query as above.
Input
Expected
The result should be the same as above except without the
object
wrapper.Actual
Instead, our enum now errors, and the expected error has disappeared.
What's happening?
value
property on an error object, which isundefined
and hides the original error.@graphql-tools/delegate defines special symbols used to annotate external objects. This is then used by defaultMergedResolver to resolve external values. Using lodash's
get()
to extractreturnData
from meshed results causes both issues.Possible solutions
get()
.returnData
via a schema transform, eg "[WrapQuery] is used to get a result nested inside other result".I've managed to achieve option 1 via patch-package in the reproduction repo linked above. It doesn't get error locations/paths correct so I'm wondering if option 2 would be more robust, but I haven't tried it yet. Note that I also had to patch merger-stitching to bypass
mergeSingleSchema()
as it wasn't settingstitchingInfo
which is required to resolve external values.The text was updated successfully, but these errors were encountered: