prisma plugin select with expose does not work properly if fetched through resolveReference

[macrozone]

Consider a federated graph where in one graph you declare an entity like this:

export const ProjectRef = builder.prismaObject("Project", {
  select: { // to load only the necessary data, you can select the fields you need
    id: true,
    name: true
  },
  fields: (t) => ({
    id: t.exposeID("id"),
    name: t.exposeString("name"),
    slug: t.exposeString("slug") // exposeString automatically selects the exposed variable, so you don't need to explicitly add this to `select`
  }),
});


builder.asEntity(ProjectRef, {
  key: [
    builder.selection<{ id: string }>("id"),
  ],
  resolveReference: (key) => {
    return prisma.project.findUnique({
      where: {
        id: key.id
      },
      // pothos correctly sets the type so i have to set the same `select` as in the objectRef
      select: {
        id: true,
        name: true
      }
    });
  },
});

If this entity is resolved in another graph and therefore resolveReference is called, slug will yield an error:

 "Cannot return null for non-nullable field Project.slug.",

It turns out that t.exposeString("slug") does not properly append the select in this case.

Workarounds:

• not using expose, but instead a normal field resolver:

slug: t.string({
      select: {
        slug: true,
      },
      resolve: (parent) => parent.slug,
    }),

• not using select in the resolveReference call. That means you will lose the efficiency gains there

[hayes]

can you try this instead:

import { queryFromInfo } from '@pothos/plugin-prisma'

builder.asEntity(ProjectRef, {
  key: [
    builder.selection<{ id: string }>("id"),
  ],
  resolveReference: (key, ccontext, info) => {
    return prisma.project.findUnique({
      ...queryFromInfo({ context, info, typeName: 'Project' }),
      where: {
        id: key.id
      },
    });
  },
});

[hayes]

Going to close this since I haven't heard back. Feel free to re-open the issue if you are still having issues after trying the above

[macrozone]

hey @hayes, sorry for the late response. Thank you for your solution.

this works, but I think its worth documenting, since its a pitfall that isn't obvious to spot. (also the passed typeName isn't typed, so its possible to make a typo there)

[hayes]

A PR to update the docs would be more than welcome!

I can't think of a good way to improve the typing of the typename here without deeply coupling the prisma and federation plugins, but open to suggestions.

[macrozone]

@hayes will do, sorry for the dealy