globalId argument not converted prior to relatedConnection.query execution

[jonapgar-groupby]

The relatedConnection.query function is executed as part of a relationSelect function which is used as the pothosPrismaSelect argument.

pothos/packages/plugin-prisma/src/prisma-field-builder.ts

Line 258 in 799b5d1

const nested = nestedQuery(getQuery(args, context), {

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 an arg 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!

[hayes]

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 query generated by Prisma takes a slightly different approach where arguments are extracted from the query rather than resolver arguments bypassing those transforms.

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

[arimgibson]

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 as unknown as string I suppose, but thought I'd throw it out there

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;
    }),

[hayes]

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.