I've simplified my code to strip away noise for you, helpful reader. I have the typical database type

User

with the typical stuff like

id: ID!

and

email: String!

, and

type: Int!

. In order to prevent emails leaking out to other users, I removed the

email

from the app schema's type `User`:

type User {
  id: ID!
  type: Int!
}

I have defined a second type

PrivateUser

that has the `email`:

type PrivateUser {
  id: ID!
  email: String!
  type: Int!
}

And I have a type

AuthPayload

to deliver my JWT along with any

PrivateUser

data I might want to use:

type AuthPayload {
  token: String!
  user: PrivateUser!
}

When I try to use Fragments this is what happens...

This is what I get when I attempt to use a fragment against my

PrivateUser

type.

So for experiment's sake, I switch my AuthPayload to

type AuthPayload {
  token: String!
  user: User!
}

And adjust my fragment to assume it's type

User

(ignore the Playground error underlining, it still thinks user is

PrivateUser

)

My login mutation code looks like this:

async login(parent, args, ctx) {
    const user = await ctx.db.query.user({ where: { email: args.email } });
    if (!user) {
      throw new Error(`No such user found for email: ${args.email}`);
    }

    const valid = await bcrypt.compare(args.password, user.password);
    if (!valid) {
      throw new Error("Invalid password");
    }

    return {
      token: jwt.sign({
        id: user.id,
        type: user.type,
        status: user.status,
        flags: user.flags,
      }, process.env.APP_SECRET),
      user,
    };
  },

My thought is: Is there something wrong with the variable

user

in that function? I can confirm that without

info

in

ctx.db.query.user()

the contents of the

user

object contains EVERYTHING that the login mutation claims to be missing in the first screenshot.

Reading https://www.prisma.io/blog/graphql-server-basics-demystifying-the-info-argument-in-graphql-resolvers-6f26249f613a/ Has revealed A LOT to me, especially the parts talking about the different Implementations of the same custom Type (applicable to my

AuthPayload

type, finally revealing to me why the GraphQL boilerplate has this file in it: https://github.com/graphql-boilerplates/node-graphql-server/blob/master/advanced/src/resolvers/AuthPayload.js )

But still, I'm left with a misbehaving Fragment. It is my theory that perhaps the binding will not match the fragment because the name

PrivateUser

does not match the internal query's type name

User

?

I made this repro repo: https://github.com/TiE23/p-b-fragments-bug @nilan if this is a bug and not just a mistake by me - is it a

prisma-binding

bug? Sorry that I don't know what project to blame this bug(?) on, as a guy who just jumped in on the 2nd floor with boilerplates there are so many modules involved that I personally can't keep them straight. 😅 I'll write an issue for it.