AssertionError: Found different types with the same name in the schema: ...

[arielnmz]

I know this has been submitted a million times, and I know there are several solutions BUT, despite all things it seems there still isn't a way to actually know where the duplicates come from, e.g. The error message would read:

AssertionError: Found different types with the same name in the schema: status, status.

But that doesn't give much information as to where do they come from. This is specially frustrating when plugging in projects. A suggestion would be to print the canonical name of the class the type is based on? something like 'my_module.types.ProblematicType'.

Anyway, this issue arises specifically because I defined a Type based on an Enum on my types module and I'm using that everywhere, but still graphql complains about different types having the same name. I double checked and I don't even use that name anywhere in my project, so it must be a conflicting dependency, but which one? where is that type being defined? The only way to know would be unplugging all dependencies and start plugging them one by one to find the offenders but this would be so inefficient and frankly, very stupid.

(in case you wonder I also searched in my site-packages and found nothing, so it must be auto generated somewhere...)

I'm using these packages:
django==2.2.9
graphene-django==2.7.1
graphene==2.1.8

And my types worked just fine with these versions:
django==2.1.5
graphene-django==2.2.0
graphene==2.1.3

[leewardbound]

Hi, I didn't want to open a new issue, but are you seeing this when using the SerializerMutation? If so, this might be the same as my issue --

I've isolated this bug in a test case -- I have verified that a simple test for adding a SerializerMutation with any simple ChoiceField causes the error to be thrown.

I think we can all agree that this test should not fail on the last line, but it throws the error E AssertionError: Found different types with the same name in the schema: status, status.

I have also submitted a PR #851 to allow us to disable this Enum creation, but I think we have positive confirmation here that these Enum types are causing schema definition collisions even in simple use cases.

[adrengifo]

when is this going to be merged and pushed?

[jkimbo]

Sorry for the delay everyone. #860 has just been released as v2.9.0 Go try it out!

[ulgens]

@jkimbo I'm not sure #860 solves this issue. If the reason of naming clash was not choices but something else, the error message is still not helpful.

[adrengifo]

still seeing the same issue with v2.9.0

[jkimbo]

@arielnmz you need to explicitly turn on the new naming scheme in v2.9.0: http://docs.graphene-python.org/projects/django/en/latest/settings/#django-choice-field-enum-v3-naming

@ulgens I agree the error message could be more helpful. Do you want to try and make a better one?

[arielnmz]

@jkimbo Sounds great! I will give it a try later this week, thank you!

[NwawelAIroume]

The solution

@arielnmz you need to explicitly turn on the new naming scheme in v2.9.0: http://docs.graphene-python.org/projects/django/en/latest/settings/#django-choice-field-enum-v3-naming

@ulgens I agree the error message could be more helpful. Do you want to try and make a better one?

@jkimbo this didn't work for me
the one that worked was adding convert_choices_to_enum = False in the metaclass of the ObjectType. here is the link https://docs.graphene-python.org/projects/django/en/latest/queries/#choices-to-enum-conversion