Unable to fetch entity after creating it in nested mutation



I’ve encountered an interesting case. If I perform a nested mutation in which I create a different object (to execute that in one transaction) and want to fetch the created nested object afterwards, it is null.

My mutation:

const result = await context.db.mutation.updateInvitation({
    data: {
      status: "ACCEPTED",
      user: {
        create: {
          username: args.data.username,
          emailAddresses: {
            create: {
              primary: true,
              address: args.data.email,
              status: "PENDING",
              verificationCode: createVerificationCode()
    where: {
      id: invitation.id

  const user = await context.db.query.user({
    where: {
      username: args.data.username

The user in the last part is null. A much cleaner way would be to fetch the created inner object from the nested mutation, but that is not possible isn’t it?


When you run this resolver, and afterwards run the query directly against the Prisma API:

  where: {
      username: args.data.username
) {

What is the result?


I receive the user object, when I run the query against the Prisma API. That’s the weird thing about it :confused:


Might be related to https://github.com/graphcool/prisma/issues/1850? :thinking:


Hm, yeah, seems to be :flushed: – Fetching a “nested object” from the nested mutation isn’t possible, right? It seems to return “only” the actual object whose mutation has been executed, but not the inner objects.

This problem hits me pretty hard at the moment, because I can’t return the created object.


You can provide a specific info string to the updateInvitation call to query the nested user. Something like this should work:

const result = await context.db.mutation.updateInvitation({
  // <snip>
}, `{users(where: { username: "${args.data.username}" }) { id }}`)

Typing the query by hand, so there might be some syntax errors! (If so, please let me know so I can edit the post :pray:)

Because you are not providing any info object, only all scalar fields are queried.

I talked more about the different cases the info argument in this post, and we recently released a blog post about this topic too :slight_smile:

Hope this let’s you work around the issue for now. I’d be curious to learn more about the underlying problem though. Clearly, it’s something in prisma-binding or one of the libraries it uses like http-link-dataloader or graphql-tools.


Oh, thanks @nilan – That helped a lot as a workaround. In my case the query looked like {acceptor(where:{username: "${args.input.username}"}) {id}} – So no syntax errors on your side. Well done :slight_smile:

I guess, I can investigate the problem in the layers below (at least file an issue if I’m stuck).


Thinking about it, querying the user directly is the better approach anyway! We will save one request :slight_smile:

Yep, help to learn more about this issue would be super cool, thanks! :raised_hands:


@nilan The problem seems to live in the http-link-dataloader respectively in the dataloader. I passed an {cache: false} to the dataloader instantiation and I receive the correct values then. I will file an issue in the http-link-dataloader repository to discuss a change in the caching behaviour.


For posterity: https://github.com/graphcool/http-link-dataloader/issues/3