-
Notifications
You must be signed in to change notification settings - Fork 96
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
convertDefinition
failing when name
== concatenated namePrefix
#305
Comments
Wow, good find. That sure is a way to construct a collision without any type names that are too weird! I think your analysis of the name is approximately right, but maybe a simpler way to see it is simply that You should be able to work around this with a Ideally we could avoid this entirely, but I don't see an obvious way short of making basically all our type names, or at least all our fragment type names, uglier/longer. (Kinda a breaking change too.) Perhaps it's time for the collision-detector to add a suffix, although we'd have to make sure it's stable in its ordering. Suggestions welcome! |
Describe the bug
I am encountering "conflicting definition" errors when using specific GraphQL field and type names with genqlient. The error message is as follows:
To Reproduce
The issue occurs under specific conditions:
For a clearer understanding and a practical demonstration, I prepared a minimal reproducible example here: https://github.com/Ynng/genqlient-bug
Expected behavior
I expect the code generation process to successfully handle these scenarios without encountering conflicting definition errors.
genqlient version
v0.6.0
Additional Information
My guess is that the issue arises when
convertDefinition()
encounters aname
that is the same asnamePrefix
list concatenated and formatted.This causes problems down the road for Unions, leading to duplicate "UnionNameImplName" definitions.
I think the issue can be traced back to these two lines:
genqlient/generate/convert.go
Line 465 in 28aafc7
genqlient/generate/convert.go
Line 496 in 28aafc7
These lines inadvertently create two conflicting definitions: one from "UnionName + ImplName" and another from "Union + Name + ImplName."
The text was updated successfully, but these errors were encountered: