Prisma and Interface issues

[jonapgar-groupby]

I believe I may have discovered a "bug" with the prisma plugin and nested interfaces.

This is a fairly complicated issue and it's not obvious to me how this could be fixed, given the way graphql-tools resolves abstract types (e.g. Interfaces).

Here's a type Ticket that implements some interfaces, including the HasRemark interface.

 const Ticket = builder.prismaNode('Ticket', {
    description:
      'A ticket is a piece of work that needs to be done by an agent',
    id: { resolve: (parent) => builder.decodeGlobalID(parent.id).id },
    interfaces: [Linkable, HasRemark, HasProject],
    select: {
      id: true,
      remarkId: true, // <======= Note  we have to manually select this here, for the HasRemark interface
      projectId: true,
    },
    ...

Consider the following query to fetch "tickets" their associated remarks and their links.

query {
  tickets {
    edges {
      node {
        id
        remark { # added via the HasRemark InterfaceRef
          id 
          content # ... resolved from another subgraph
        }
        project { # added via the HasProject InterfaceRef
          id 
        }
        # Tickets can be linked to "Linkable" implementations
        linkedTo {        
          edges {
            node {
              __typename # "Link"
              
              reference { # Linkable interface
                id
                ... on Ticket { # Tickets are Linkable
                  title # This works!
                  remark { # resolved via the HasRemark InterfaceRef again
                    id # This doesn't resolve properly because the HasRemark InterfaceRef is resolved with the Linkable parent, not the Ticket
                  }
                  project {
                    id # same issues as above...
                  }
                }
              }
              
            }
          }
        }
      }
    }
  }
}

Example response:

{
  "data": {
    "tickets": {
      "edges": [
        {
          "node": {
            "id": "Ticket:clixe5rtw0029plgz6vjqrzyj",
            "remark": {
              "id": "Remark:clixe5rtx002bplgz104fysid",
              "content": "foo bar"
            },
            "project": {
              "id": "Project:clixe5bfq001eplutndaaqpmi"
            },
            "linkedTo": {
              "edges": [
                {
                  "node": {
                    "reference": {
                      "title": "A linked ticket",
                      "remark": {
                        "id": "Remark:"
                      },
                      "project": {
                        "id": "Project:"
                      }
                    }
                  }
                }
              ]
            }
          }
        },
        ...

The Remark id is resolved correctly in the initial Ticket, but in the linked Ticket, the HasRemark InterfaceRef remark field receives a Linkable as the parent, not the complete Ticket which should include the selected fields including remarkId.

// ... This is part of a factory for creating external references...

builder.interfaceType(
    builder.interfaceRef<{ [key in F]: string }>(`Has${typename}`),
    {
      name: `Has${typename}`,
      description: `An object that has a ${typename}`,
      fields: (t) => ({
        [typenameToLowerCase(typename)]: t.field({
          type: externalRef,
          resolve: (parent) => {
            return {
              id: builder.encodeGlobalID(typename, parent[hasField]), // <======= property hasField is `F` and should be present. 
            };
          },
        }),
      }),
    }
  );

When resolving the Linkable into a Ticket, each field resolver is called separately in parallel. The resolver for the title field on the Ticket is resolved via Prisma automatically by the Prisma Plugin, but the remark field here is resolved on this InterfaceRef

There is a workaround for this, but it's not ideal. In the resolver for the field that returns an interface, you can return the entire object and not just the interface fields.

      resolve: async (parent, args, context, info) => {
          const linkable = { id: parent.reference };
          return linkable;
          // Sadly, we can't simply return { id: parent.reference } for any of Linkable implementations _that are defined in this subgraph_
          // (It works for external Linkable types because additional fields are resolved by the router and fetched from the appropriate subgraph)
          const { typename, id } = builder.decodeGlobalID(parent.reference);
          const query = queryFromInfo({
            context,
            info,
            typeName: typename,
            path: ['reference'],
          });
          switch (typename) {
            case 'Ticket':
              return {
                ...(await prisma.Ticket.findUnique({
                  // ...query, // <====================== This would be nice, but doesn't actually contain the desired `remarkId` field 
                  where: { id },
                })),
                // Unfortunately, we need to override the selected id from the prisma result above in order to preserve our globalId which will be decoded when the result of the Ticket is resolved.
                ...linkable, // override id with globalId
              };
              ...

As you can see, you cannot actually use the queryFromInfo here either because it doesn't have any way of knowing that it needs the remarkId field.

I guess the way to solve this within pothos would be to allow interface fields to contain a select with a required field and then limit them to being used on Prisma objects. I'm not sure how that would work though...

[hayes]

This is definitely a complex case...

I don't have a perfect solution here, but something that may help is that you can pass in a default selection to queryFromInfo

const query = queryFromInfo({
  select: { remarkId: true },
  context,
  info,
  typeName: typename,
  path: ['reference'],
});

This is just adding to your workaround, and not a real solution. It's pretty challenging for Pothos to resolve this, because the prisma query needs to be calculated before the data is resolved, so it can't know the concrete type of the interface, unless it's hinted at though an argument (eg, your example the typename is encoded in the ID, but pothos wouldn't know that).

Putting selections on interface fields is also kinda tricky, because implementors of interfaces may be completely different, using different tables, or may not even be prisma objects. You can manually add this info tho (you just need to add an extension with a select function to your field (https://github.com/hayes/pothos/blob/main/packages/plugin-prisma/src/index.ts#L57-L72)

remark: t.field({
  type: ...,
  resolve: ...,
  extensions: {
    pothosPrismaSelect: () => ({ remarkId: true })
  }
})

This is using internal functionality that I won't guarantee will work forever, but I also don't have any plans to change how this works in the future.

I'm not 100% sure this works, because since I haven't tested it, but hopefully this gives you an ideas for next steps

[jonapgar-groupby]

Thank you for your response! I did see extensions.pothosPrismaSelect when I was digging through the code and was unsure of how I may be able to leverage that.

The complexity here is obviously not ideal and mostly only exists because of the federated architecture I'm working with. Otherwise, I would just use t.relation everywhere and things would be a lot simpler :)

I will update the discussion here in case anyone else encounters similar issues.