Possibly unhandled Error: Schema must contain unique named types but contains multiple types named "Organization"

[KyleAMathews]

I saw this after upgrading to 0.4.2. But I only have one type named Organization so confused what's happening. I remember reading something that all types had to be defined in the same file? Is that still true? I'm not doing that atm. 0.3.0 works fwiw.

[KyleAMathews]

And oddly this error only shows up in production. I can't for the life of me reproduce in on my dev server.

[KyleAMathews]

And it's actually 0.2.6 that works.

[leebyron]

Types do not have to be defined in one file. 0.4.x added the schema validation checks, the previous versions allowed the use of invalid schema, so it's likely that your schema is in fact invalid.

Maybe one place to look is if you're calling the "new GraphQLXType()" constructors more than once per type? Perhaps you're defining them within a function that's being called multiple times rather than just at the top level of a module?

Let me know what you find. I would like to learn what issues people encounter so I can make the error messages more actionable.

[KyleAMathews]

Finally got back to this. You were 100% correct @leebyron, I was (somewhat accidentally) calling new GraphQLXType() multiple times due to the weird way I was integrating with Hapi. Each object type was in a separate file and I was passing the server object to each type instead of using rootValue so each time the type was required it'd get created again.

I think the error is sufficient. I just needed to up my Node skills a bit to figure out what was wrong.

[leebyron]

Ah, good to know. Thanks for the update!

[ryanblakeley]

@leebyron I'm trying to split up my Types into separate files and am running into the same error. Is there any documentation or an example of the right way to do this?

I understand that we want to avoid calling new GraphQLXType() more than once for a given Type. If a Type has its own dedicated file which may be imported multiple times, it seems like you would not be able to have that constructor call in that dedicated file.

So is another way to construct a Type in a top-level module, and assign its fields in a dedicated file?

[leebyron]

As long as it is defined in that file once, you should be okay. Node only will run a file one time and then return the same previously run export if it's included from another file.

[rogchap]

I've got a similar problem, that I'm not sure if it's an issue with graphql-js or graphql-relay-js. My UserType is declared like the following in es2015/6:

// userSchema.js

export const UserType = new GraphQLObjectType({
    name: 'User',
    description: 'A person who uses our app',
    fields: () => ({
      id: globalIdField('User'),
      // ... other fields here
    }),
    isTypeOf: typeCheckFn,
    interfaces: [nodeInterface],
  });

and then my query:

// userQuery.js

import { UserType } from './userSchema';

export default {
  viewer: {
    type: UserType,
    description: 'Current authenticated user.',
    async resolve(_, args) {
      //... resolve here
    },
  },
};

At this point my GraphQL Relay Server is working as expected. :smile: The error (in the subject of this issue) occurs when I import the UserType in another file somewhere; e.g:

// userMutations.js

import { UserType } from './userSchema'; // <-- This causes the error.

I've been digging around for a while now, and the reason I think this might be related to relay-js is that the error goes away when I remove nodeInterface from my interfaces.

I've tried everything, but can't see a way to solve this.

@leebyron would be super grateful if you had any thoughts. From your last comment I'm wondering if it's an issue in the way I'm using node/babel.

[rogchap]

UPDATE:

@leebyron Your last comment got me thinking, and I checked if my file was being exported more than once... and it was!

Was trying to find out what would cause this, and I found that it would only get called once if I moved the file to different folder. eg:

// userMutations.js

import { UserType } from '../schemas/userSchema'; // <-- No longer an error

Very strange!

To further test I created a new file in the same directory as userQuery.js and userMutations.js:

--- models
   |--- schemas
       |--- userSchema.js 
   |--- user
       |--- userQuery.js
       |--- userMutations.js
       |--- testFile.js

testFile.js only contains a log statement:

// testFile.js
console.log('Duck')

Then I require the testFile in both user files:

// userQuery.js
require('./testFile');

// userMutations.js
require('./testFile');

Sure enough "Duck" is outputted twice in the console, but as soon as I move this test file somewhere outside of this directory it only logs once again.

Mystery continues....

[stephenbaldwin]

check the capitalization of the files your importing. OSX file system is case-insensitive by default. Node caches files based on path so if you refer to a file twice with two different capitalizations it will load the file twice. i.e.

// foo.js
console.log('foo');

// index.js
import foo from './Foo'; // => logs foo
import foo1 from './fOo'; // => logs foo
import foo2 from './foo'; // => logs foo
import foo3 from './Foo'; // => does not log foo

[mormahr]

@stephenbaldwin Someone needs do document this somewhere visible... I've been pulling my hair out to find this error 😤😅

[gdenn]

This seems to be a bit outdated now, but i was facing the same Problem. My mistake was that i declared two types in my Schema with the same attribute name: 'User'. Thus graphql recognized that i declare the type User twice. cheers

[gsjurseth]

I'm receving this error now but I believe that my use case is a bit different. I've got a type called "DailyAverage" that has an object like so

{ "Date": "2017-08-06", "Minutes": "1322.232" }

Now .. I'm trying to use this type twice as a list ... Once for UserAverages and once for CommunityAverages, but when I do this I get the above error.... If I simply duplicate the DailyAverage definition verbatim with the name CommunityDailyAverage and update the reference accordingly it works ... No surprise there.

My question is why this restriction? It seems like it's some sort of hardcoded query validation that forbids the use of reusing a self-declared type more than once at all.

[jarnoux]

I've encountered this same error when using a type as a member of an input. The mistake was that only an input can be member of an input. I'd suggest returning a message to that effect instead.

[IvanGoncharov]

@jarnoux Can you please try it with 14.0.0-rc.2 and if you manage to reproduce issue can you please post the minimal example here?

[leogoesger]

I ran into similar issue when I move files around and change the casing. I solved it by naming the file to something else, then change it back. Everything worked after! I think Node is caching some of the files!

[sorousht]

I've had the same issue with GraphQLUnionType until I found that two GraphQLObjectType have the same name!

// fooType
export const fooType = new GraphQLObjectType({
  name: 'Foo',
  fields: () => ({
  ...

// barType
export const barType = new GraphQLObjectType({
  name: 'Foo', //  The problem!
  fields: () => ({
  ...

// unionType
export const unionType = new GraphQLUnionType({
  name: 'Union',
  types: [
    fooType,
    barType,
  ],
  ...

[audiBookning]

Just adding my experience in the case that it could help someone. I had the same problem and it happened after renaming some files. The various solutions suggested didn't help unfortunately.

Only when i deleted the dist folder ('transpiled/compiled' code) was that the error disappeared.

Some info on my case: Backend with Nestjs, Git and using VS Code. I even began to think that git was somehow the culprit. I hope that he/it can forgive me ;)

[hardikmodi1]

I was using type-graphql and facing the same issue, here is my code https://github.com/hardiked/Slack/tree/master/packages/typegraphql_boilerplate. When I compiled the code with "tsc" and hen tries to run it, it says that "Error: Schema must contain uniquely named types but contains multiple types named "Message"."

[sibelius]

@hardikmodi1 did you figure it out?