-
Notifications
You must be signed in to change notification settings - Fork 66
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
Some types don't resolve anymore after updating to 1.2.1 #86
Comments
Oh dang! Thanks for reporting @cshadek! From a quick initial investigation, I'm seeing that the Graphiti tests for resolution are passing on union types, array types, and type fields within arrays. We don't seem to have any tests on Do you have a schema I could use to recreate the issues you are seeing? It would help me diagnose the issue and I'd love to use it to write testing coverage if we're missing it. Thanks again! |
Thanks for getting back so quickly @NeedleInAJayStack! So I'm not entirely sure why this worked, but I was able to get the Union types and Array types to resolve by changing how the schema was declared. I was using the old way:
and am now doing it as recommended:
For some reason this one change caused the Union and Array types to resolve. I don't really understand why. Still the connection types are not resolving and then also it seems that nested types inside array types are not resolving either. Unfortunately, I can't share the exact schema as it's proprietary. Here's an example:
ParentObject, ObjectA, ObjectB, and ObjectC are all I haven't confirmed yet if the schema I just created above resolves or not. I'll check on that, but this is a rough recreation of the schema in question. In my schema when I comment out the line with the array, all the types resolve. So, I figure it must have to do with the array part. The actual schema is much more extensive, but this is what seems to be causing a problem. For some reason, ObjectB and ObjectC don't get resolved unless I include them in the The only other cause I could think of is if the depth of the schema graph matters. Both ObjectB and ObjectC in my case are nested several layers down the graph. |
Darn, I'm still having trouble recreating this. I built the test file below based on your example and everything still worked. What is the specific error that you are seeing? And is it on the Schema creation or the query resolution step? import Graphiti
import NIO
import XCTest
private protocol InterfaceA: Codable {
var interfaceAField: String? { get }
}
private protocol InterfaceB: Codable {
var interfaceBField: String? { get }
}
private struct ParentObject: Codable, InterfaceA, InterfaceB {
let interfaceAField: String?
let interfaceBField: String?
let objects: [ObjectA]
}
private struct ObjectA: Codable, InterfaceA {
let interfaceAField: String?
let objectB: ObjectB?
let objectC: ObjectC?
}
private struct ObjectB: Codable {
let scalar: String
}
private struct ObjectC: Codable {
let scalar: String
}
private struct TestResolver {
func parentObject(context _: NoContext, arguments _: NoArguments) -> ParentObject {
return ParentObject(
interfaceAField: "ParentObject is A",
interfaceBField: "ParentObject is B",
objects: [
ObjectA(
interfaceAField: "ObjectA1 is A",
objectB: ObjectB(scalar: "I'm A1's B"),
objectC: ObjectC(scalar: "I'm A1's C")
),
ObjectA(
interfaceAField: "ObjectA2 is A",
objectB: ObjectB(scalar: "I'm A2's B"),
objectC: ObjectC(scalar: "I'm A2's C")
)
]
)
}
}
private class TestAPI<Resolver, ContextType>: API {
public let resolver: Resolver
public let schema: Schema<Resolver, ContextType>
init(resolver: Resolver, schema: Schema<Resolver, ContextType>) {
self.resolver = resolver
self.schema = schema
}
}
class ReportedTests: XCTestCase {
func testReportedError() throws {
let testSchema = try Schema<TestResolver, NoContext> {
Interface(InterfaceA.self) {
Field("interfaceAField", at: \.interfaceAField)
}
Interface(InterfaceB.self) {
Field("interfaceBField", at: \.interfaceBField)
}
Type(ParentObject.self, interfaces: [InterfaceA.self, InterfaceB.self]) {
Field("interfaceAField", at: \.interfaceAField)
Field("interfaceBField", at: \.interfaceBField)
Field("objects", at: \.objects, as: [ObjectA].self)
}
Type(ObjectA.self, interfaces: [InterfaceA.self]) {
Field("interfaceAField", at: \.interfaceAField)
Field("objectB", at: \.objectB, as: ObjectB?.self)
Field("objectC", at: \.objectC, as: ObjectC?.self)
}
Type(ObjectB.self) {
Field("scalar", at: \.scalar)
}
Type(ObjectC.self) {
Field("scalar", at: \.scalar)
}
Query {
Field("parentObject", at: TestResolver.parentObject)
}
}
let api = TestAPI<TestResolver, NoContext>(
resolver: TestResolver(),
schema: testSchema
)
let group = MultiThreadedEventLoopGroup(numberOfThreads: System.coreCount)
defer { try? group.syncShutdownGracefully() }
print(
try api.execute(
request: """
query {
parentObject {
interfaceAField
interfaceBField
objects {
interfaceAField
objectB {
scalar
}
objectC {
scalar
}
}
}
}
""",
context: NoContext(),
on: group
).wait()
)
// Prints:
// {
// "data": {
// "parentObject": {
// "interfaceAField": "ParentObject is A",
// "interfaceBField": "ParentObject is B",
// "objects": [
// {
// "interfaceAField": "ObjectA1 is A",
// "objectB": {
// "scalar": "I'm A1's B"
// },
// "objectC": {
// "scalar": "I'm A1's C"
// }
// },
// {
// "interfaceAField": "ObjectA2 is A",
// "objectB": {
// "scalar": "I'm A2's B"
// },
// "objectC": {
// "scalar": "I'm A2's C"
// }
// }
// ]
// }
// }
// }
}
} |
Sorry for just jumping to the conversation here. I am also interested in which types wouldn't resolve and whether that's an issue during the schema building or the resolving process. In my case, Both Union and Array types are working fine for me, even with using func schema() throws -> Schema<Resolver, Context> { Resolving unionResolving other types within an ArrayI have the working example here https://github.com/d-exclaimation/pioneer-example/tree/v1 Not sure whether there are other requirements needed to recreate the issue or whether my example is even relevant to the issue to begin with. |
Hey @cshadek, have you been able to get a reproducer of this issue? If not, I'm planning to close it with the |
I was able to fix the issue by reordering some of the declarations, and I'm still not sure why the issue was happening. It's still a problem with ConnectionTypes right? I haven't checked in a while - I still have a Types block with all my ConnectionTypes. |
@NeedleInAJayStack, so I just checked and ConnectionTypes seem to work fine now without the Types block, so I'll close this issue. |
After removing the
Types
construct as recommended in #84, some types don't resolve anymore.So far I've been able to narrow it down to:
Types
constructIf I keep the
Types
construct (which is deprecated) to include the types above and still remove all instances ofTypeReference
in the schema, it resolves.The text was updated successfully, but these errors were encountered: