-
-
Notifications
You must be signed in to change notification settings - Fork 150
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
globalId argument not converted prior to relatedConnection.query execution #988
Comments
This is an interesting bug. Almost all Pothos runtime behavior is implemented through resolvers in the GraphQL schema. Things like deciding global IDs and validation happens inside the resolver for a field. The The fix here will likely require a way for plugins to define those transforms/checks in a way that other plugins can automatically apply them. I'll have to play around with this and see if there's an easy way to do that |
Wondering if it's possible to update the typing in this situation, if that's easier than an actual fix? Just ran into this too and Pothos still types the return data as the decoded global ID format instead of a string. Not a huge deal to Edit: actually, to build on what @jonapgar-groupby said, it appears as if sometimes it does actually process it correctly? Not sure where that's happening... args: {
campaignIds: t.arg.globalIDList(),
}
args.campaignIds.map((id) => {
console.log(id);
return decodeGraphQLGlobalID(id as unknown as string).id;
}),
// Input
campaignIds: ["Campaign:clvhjotez09c1io8idjf3yekq"],
// Console logged
Campaign:clvhjotez09c1io8idjf3yekq
Campaign:clvhjotez09c1io8idjf3yekq
{
typename: "Campaign",
id: "clvhjotez09c1io8idjf3yekq",
}
// Working processor (with no type errors)
args.campaignIds.map((id) => {
if (typeof id === 'string') return decodeGraphQLGlobalID(id).id;
return id.id;
}), |
The current behavior is definitely a bug, and updating the types is probably the wrong solution. The way to fix this will requires creating a mechanism to parse input/argument values across plugins, so the Prisma can know how to decide the IDs outside the normal resolver flow. This shouldn't be too complex. Pothos already has utils for mapping arguments, it just doesn't store anything about these mappers in the schema in a way another plugin could use it. |
The relatedConnection.query function is executed as part of a
relationSelect
function which is used as thepothosPrismaSelect
argument.pothos/packages/plugin-prisma/src/prisma-field-builder.ts
Line 258 in 799b5d1
This apparently means that the
query
function is being called prior to the args being unwrapped (and perhaps prior to validation too?). As a result anarg
on a relatedConnection could contain an incorrect value (such as the full globalId instead of the decoded value).For globalIds it's not very hard to work around, because I can just check if they are a string and decode them myself, but it took me a while to track down that this was even happening at all.
Hopefully this issue helps anyone facing a similar problem!
The text was updated successfully, but these errors were encountered: