Repository navigation
0.10: GraphQL typing ignores load option #1150
Description
We have a mutation with an argument that uses GraphQL's loads option, which auto-fetches objects by their ID.
It looks like this: argument :party_ids, [ID], loads: Types::PartyType, as: :parties
The type of the argument coming in to resolve is then T::Array[Party], but the new compiler thinks they're still T::Array[String]
cc @jeffcarbs -- just an FYI, no expectation that you fix this, thanks for the work!
Activity
fazo96 commentedon Oct 27, 2023
Seems like this is fixed by #1556
xinyifly commentedon May 23, 2024
@fazo96 I think current graphql_mutation compiler resolves to something like
T::Array[Types::PartyType]instead ofT::Array[Party]fazo96 commentedon May 31, 2024
That's true @xinyifly I have noticed the same behavior recently
rmosolgo commentedon Oct 6, 2026
I took a look at this but found that it's a tougher problem than I realized. GraphQL-Ruby's
loads: ...option expects a GraphQL type class, not an application class. Under the hood, GraphQL-Ruby takes the given ID, loads an object for it (GraphQL-Ruby itself doesn't know what kind of object to expect), then calls the schema'sresolve_typehook to make sure that the loaded object does in fact resolve to the configuredloads: ...type.But
def resolvereceives the application object, not the GraphQL type. In order for this to work right, we'd need a consistent way to go from a GraphQL type class (egTypes::PartyType) to the Rails class it uses under the hood (eg::Party). But GraphQL-Ruby itself never actually enforces a one-to-one mapping in this way -- it only requires an object that quacks like aTypes::PartyType.Because there's no existing basis for this one-to-one mapping, I'm not sure how this could be statically improved. I'm going to keep using one-off sigs 😖