Getting multiple instances of graphql error despite only having a single version

[link2cory]

I wasn't sure whether or not to make a new issue or comment on #594 but that one is so old I figured it would be preferable to start anew

In my project I get the "ensure that there are not multiple versions of GraphQL installed in your node_modules directory" error despite having done so.

yarn list output:

yarn list --pattern graphql                   
yarn list v1.22.5
├─ @apollographql/apollo-tools@0.4.8
├─ @apollographql/graphql-playground-html@1.6.26
├─ @types/graphql-upload@8.0.4
├─ apollo-graphql@0.5.0
├─ graphql-extensions@0.12.4
├─ graphql-scalars@1.2.7
├─ graphql-tag@2.11.0
├─ graphql-tools@4.0.8
├─ graphql-upload@8.1.0
└─ graphql@15.3.0
Done in 0.87s.

and for posterity:

find node_modules -name graphql
node_modules/graphql

My tech stack includes apollo-server-lambda and nexus-schema. Not sure if/how one of them could be behind this, but the issue only cropped up after switching from apollo-server-express to apollo-server-lambda. Nevertheless, it would seem that graphql-js is reporting this error erroneously as I have proven there is only one instance of graphql in my node_modules directory.

exact error message:

Error: Cannot use GraphQLObjectType "Bio" from another module or realm.                                  
                                                                                                         
Ensure that there is only one instance of "graphql" in the node_modules                                  
directory. If different versions of "graphql" are the dependencies of other                              
relied on modules, use "resolutions" to ensure only one version is installed.                            
                                                                                                         
https://yarnpkg.com/en/docs/selective-version-resolutions                                                
                                                                                                         
Duplicate "graphql" modules cannot be used at the same time since different                              
versions may have different capabilities and behavior. The data from one                                 
version used in the function from another could produce confusing and                                    
spurious results.

Link to my project repo: https://github.com/link2cory/portfolio-backend/tree/serverless
a quick note: although it is not in the current version of my repo, I have tried making use of the resolutions yarn with exactly the same results. Plus the evidence I have provided above suggests to me that it should not be necessary based on my project dependencies.

Please correct me if I am wrong in any of these assumptions!

[onhate]

hi @link2cory I'll check what is going on

[onhate]

@link2cory I was afraid it was the bundler that was making the mess and on runtime despite having a single version graphql it was creating different instances of the imports, so I've made a simple test by replacing the serverless-plugin-typescript to use serverless-plugin-parcel by running:

yarn add -D parcel-bundler serverless-plugin-parcel
yarn remove serverless-plugin-typescript

and changing the plugins config on serverless.ts to:

 plugins: ['serverless-plugin-parcel', 'serverless-offline']

and now it works great and it has also reduced the bundle size from 32MB to a few Kbs, which is great for your lambda performance.

I'll continue investigate further on how to improve the version collision detection.

[link2cory]

Wow thank you so much for your help!

[IvanGoncharov]

@onhate Thanks for detailed investigation 🕵️
Can we improve error messages to help users to detect such issues faster?

[link2cory]

@onhate

Sorry for the delay here, but I do have some updates.

It turns out that the parcel solution didn't actually work in deployment. I think because the dependencies weren't actually being bundled which while it circumvented the problem, doesn't really solve it for the serverless deployment that I am trying to achieve.

So I kept trying different webpack configurations until I came across this issue #1174

So I tried setting the NODE_ENV to 'production' and that seems to work. So I believe the real issue comes down to false positives introduced by the minification process. Not sure if this can be improved within graphql-js or just means I need to adjust my development setup for use with serverless-offline. I will report back if I come up with something.

[link2cory]

Well it looks like my NODE_ENV=production workaround led me right back to a dead end. All but the first request I make to my offline lambda result in an error saying that we expected a GraphQLSchema.

I have traced this error back to assertSchema in src/type/schema.js, which calls the util function instanceOf Which is exactly the function that was edited in the issue I posted in my previous comment.

I added some console logging to the assertSchema function in src/type/schema.js so that it looks like as follows:

function assertSchema(schema) {
  console.log(
    `this is the supposed schema's constructor: ${schema.constructor.name}`
  );
  if (!isSchema(schema)) {
    console.log("it is NOT a GraphQLSchema")
    throw new Error(
      "Expected ".concat(
        (0, _inspect.default)(schema),
        " to be a GraphQL schema."
      )
    );
  }
  console.log("it IS a GraphQLSchema");

  return schema;
}

So now when I run my lambda in production but offline i get the following output from 2 identical requests to the local endpoint:

this is the supposed schema's constructor: GraphQLSchema
it IS a GraphQLSchema
this is the supposed schema's constructor: GraphQLSchema
it IS a GraphQLSchema
this is the supposed schema's constructor: GraphQLSchema
it IS a GraphQLSchema
offline: (λ: graphql) RequestId: ckfbsdo3c00020ozm9kud8nxo  Duration: 1001.04 ms  Billed Duration: 1100 ms
offline: [200] {"body":"{\"data\":{\"username\":{\"name\":\"cory\"}}}\n","statusCode":200,"headers":{"Content-Type":"application/json","Content-Length":"38","access-control-allow-credentials":"true","access-control-allow-headers":"Authorization","access-control-expose-headers":"Authorization"}}

offline: POST /dev/graphql (λ: graphql)
this is the supposed schema's constructor: GraphQLSchema
it IS a GraphQLSchema
this is the supposed schema's constructor: GraphQLSchema
it is NOT a GraphQLSchema
offline: (λ: graphql) RequestId: ckfbsdrpe00050ozma1be43tp  Duration: 222.42 ms  Billed Duration: 300 ms
offline: [500] {"body":"{\"errors\":[{\"message\":\"Expected { __validationErrors: [], description: undefined, extensions: { nexus: [NexusSchemaExtension] }, astNode: undefined, extensionASTNodes: undefined, _queryType: Query, _mutationType: undefined, _subscriptionType: undefined, _directives: [@include, @skip, @deprecated, @specifiedBy], _typeMap: { Bio: Bio, String: String, Query: Query, Boolean: Boolean, __Schema: __Schema, __Type: __Type, __TypeKind: __TypeKind, __Field: __Field, __InputValue: __InputValue, __EnumValue: __EnumValue, __Directive: __Directive, __DirectiveLocation: __DirectiveLocation }, _subTypeMap: {}, _implementationsMap: {}, _extensionsEnabled: true } to be a GraphQL schema.\",\"extensions\":{\"code\":\"INTERNAL_SERVER_ERROR\"}}]}\n","statusCode":500,"headers":{"Content-Type":"application/json","access-control-allow-credentials":"true","access-control-allow-headers":"Authorization","access-control-expose-headers":"Authorization"}}

I find this all very odd. It would seem that the schema I am providing is sometimes (all but the first request) being replaced by a similar one with a different prototype of the same name: GraphQLSchema. Since everything after my lambda handler creation is handled by Apollo-server-lambda, I suppose it is worth digging through their source as well to see if I can figure out what is going on.

[onhate]

hi @link2cory , thanks for the detailed investigation, when I had run the lambda offline bundled with parcel it has worked fine, but indeed there's something else in the equation, I'll take some time to go deep in the scenarios you provided and see how to improve the false positive cases.

[onhate]

@link2cory I think I finally discovered the root cause, it happens that serverless-offline uses worker threads to run the lambdas by default. Well, what that means, it means that the the lambda is instantiated in one worker thread and run in a different execution context so the Nexus schemas that are generated in the setup time uses one instance of graphql while the runtime checks after the lambda is setup uses a different instance of graphql.

By setting the following on serverless.ts it tells the serverless offline plugin that each request should run in a unique process, from setup to execution and in that case it will have the same graphql instance when nexus builds the schema and when graphql-js runs schema. This is similar to what happens in production, the same execution context is used on lambda setup and when requests are processed.

  custom: {
    'serverless-offline': {
      useChildProcesses: true
    }
  }

[yaacovCR]

Of course, the instanceOf check is kind of complex....

what the user is trying to do is to make sure that the object is a schema.

But instead what the user does is check that the object is a schema instantiated with the same instance of the constructor for a schema.

but what we want the user to do is to check that the object is a schema instantiated with the same version of the constructor for a schema regardless of instance.

Maybe it makes sense instead to store metadata within the object that can use duck typing to easily check for whether it is a schema or not.

Same goes for the other type system objects...

And metadata can be added to determine what version of GraphQL the schema / type system object was created with...

Just thinking out loud...

[IvanGoncharov]

@yaacovCR Fully agree that current approach is problematic however there are two problems with checking metadata:

1. Naive implementation will result in a measurable slowdown on production build, not sure but maybe it is solvable.
2. It will uncover a bunch of other issues. Example from top of my head:

   graphql-js/src/language/visitor.js

   Line 137 in b9cf5f3

   export const BREAK: { ... } = Object.freeze({});

   
   Visitors created by one instance and passed to visit from other instances will lose the ability to use BREAK.
   We can rewrite all such places to use Symbol.for or something else but it very easy to write such code in the future.

[yaacovCR]

Not sure why there would be production slowdown, in production we are doing:

value instanceof constructor

Could do

value.kind === SCHEMA

Is that really slower if use symbol?

In development could do:

value.kind === SCHEMA && value.version === VERSION