TypeError: Cannot use 'in' operator to search for 'Remote_User' in undefined" when stitching a remote gql-modules schema

[Niccolò Belli]

Describe the bug

Whenever you try to stitch a remote schema which makes use of graphql-modules you will get TypeError: Cannot use 'in' operator to search for 'Remote_User' in undefined" for every query which makes use of the remote.

To Reproduce
Steps to reproduce the behavior:

1. Clone https://github.com/darkbasic/accounts/tree/graphql-modules-stitching-error
2. pnpm install && pnpm compile
3. Run examples/accounts-boost: docker-compose up -d && pnpm start:micro
4. Go to http://localhost:4000/ and run the following query: { Remote_getUser { id } }
5. Watch for the error

Expected behavior

Stitching should work.

Environment:

• OS: Arch Linux
• @graphql-modules 1.4.4:
• NodeJS: v14.18.0

Additional context

The previous example is so simple that we're not basically stitching anything, just using the remote schema as is:

const accounts = await accountsBoost({
  tokenSecret: 'terrible secret',
  micro: true, // setting micro to true will instruct `@accounts/boost` to only verify access tokens without any additional session logic
  schemaBuilder: () =>
    stitchSchemas({
      subschemas: [remoteSubschema],
    }),
});

Yet this is enough to trigger the error. The problem has already been fixed in latest GraphQL Tools, but unfortunately @graphql-modules ships ancient versions:

graphql-modules 1.4.4
└─┬ @graphql-tools/wrap 7.0.8
  └── @graphql-tools/delegate 7.1.5

You can easily fix this with pnpm overrides:

  "pnpm": {
    "overrides": {
      "graphql-modules@1.4.4>@graphql-tools/wrap": "^8.3.0"
    }
  },

but unfortunately that could potentially regress elsewhere.

I would feel more confident to use v1 in accounts-js if it shipped with official support for graphql-tools v8 rather than force-overriding its dependencies: accounts-js/accounts#1148

[Dotan Simha]

@ardatan any idea why this happens?

[Niccolò Belli]

@dotansimha I see that you've already implemented the suggested fix in v2, so I'm closing this.