-
Notifications
You must be signed in to change notification settings - Fork 67
Fix exception thrown when two classes with the same name (but not the same fully-qualified name) are registered in a Schema #137
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
Conversation
The preferred way to deal with this is to manually disambiguate de type names by explicitly setting the names in the initializers. Creating the name from the type name is just a convenience. |
Oh, I just realized there's a crash involved. We should probably throw an error instead with a nice error message explaining what happened and suggesting the user to disambiguate the names manually by explicitly setting them through the initializers. |
Do you mean this initializer (and its overloads) ? Graphiti/Sources/Graphiti/Type/Type.swift Lines 109 to 115 in 927ebb1
Because I specify the type name using the Type(UserView.Public.self, as: "UserView_Public") {
Field("id", at: \.id)
Field("displayName", at: \.displayName)
}
Type(
UserView.Private.self, as: "UserView_Private"
) {
Field("id", at: \.id)
Field("displayName", at: \.displayName)
Field("mainEmail", at: \.mainEmail)
Field("createdAt", at: \.createdAt)
Field("updatedAt", at: \.updatedAt)
}
Type(EmailView.Private.self, as: "EmailView_Private") {
Field("address", at: \.address)
Field("optInNotifications", at: \.optInNotifications)
} It's basically the whole schema for now (if we omit for a The last
here in the code: Graphiti/Sources/Graphiti/Definition/TypeProvider.swift Lines 13 to 27 in 927ebb1
I placed a breakpoint on the throw statement inside the guard block, and after inspecting the value of
The I've been tempted to refactor the code to use |
Sorry, my bad, there's no crash in Graphiti ! We had a |
Tests are all green on my local environment
@paulofaria Is there anything specific in the CI environment that could cause the tests to crash? I also think it might be the first PR that runs tests using Xcode 16. I checked the last merged PR checks and the CI ran with Xcode 15.4. |
Ah yeah, I've validated that this CI fails on main with the same error, so it doesn't appear to be related to your changes: https://github.com/GraphQLSwift/Graphiti/actions/runs/9586143166/job/26433471298?pr=138 |
OK, yeah you were exactly right on the v16 XCode version. We were using XCode From this (totally official) site, it looks like XCode 16 is using Swift 6, which would explain some significant behavior changes. We've got a bit of work to do to become Swift 6 compatible, but that's a separate effort. Once the MR linked above is merged, feel free to rebase on it and we'll get these changes in. Thanks for contributing!! |
Alright the linked PR is merged. You should be good to rebase! |
Same name yes, but not the same fully qualified name (including the module name and potential nesting)
@NeedleInAJayStack Rebased! 😊 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks!
@abidon This change has been released in tag 1.15.1: https://github.com/GraphQLSwift/Graphiti/releases/tag/1.15.1 |
Description
This fix aims to mitigate exception thrown when registering two types that have the same name but not the same fully qualified name.
Since the actual implementation of AnyType.hashValue uses
String(describing:)
to get the type name, bothString(describing: UserView.Public.self)
andString(describing: OrganizationView.Public.self)
would return"Public"
:Graphiti/Sources/Graphiti/Definition/AnyType.swift
Lines 8 to 10 in 927ebb1
The same happen for types that aren't nested but in different modules – such as two libraries/frameworks/SPM-targets – as long as the type name themselves are the same.
Proposed solution
With my limited knowledge of the Graphiti codebase, I can see two ways to fix this (always happy to discuss a better implementation with guidance from the maintainers):
String(reflecting:)
to compute the hash code (which returns the fully qualified class name, i.e. "NameOfTheSwiftModule.UserView.Public").I preferred solution 2 as the
String(reflecting:)
documentation states suitable for debugging. Therefore I avoid building production ready solutions on this.Swift version
swift-driver version: 1.109.2 Apple Swift version 6.0 (swiftlang-6.0.0.3.300 clang-1600.0.20.10)
Target: arm64-apple-macosx15.0