Prisma Client Extensions and Interactive Transactions

[captain-http]

I am attempting to generate an audit log using Prisma Client Extensions by intercepting all model operations as defined in the provided script.

const auditLog = Prisma.defineExtension((prisma) =>
  prisma.$extends({
    name: "auditLog",
    query: {
      $allModels: {
        $allOperations: async ({ model, operation, args, query }) => {
          const result = await query(args);

          await prisma.auditLog.create({
            data: {
              model,
              operation,
              args: JSON.parse(JSON.stringify(args)),
            },
          });

          return result;
        },
      },
    },
  })
);

The extension works as expected, except for interactive transactions. Suppose you got the following interactive transaction:

await prisma.$transaction(async (tx) => {
  const report = await tx.report.findUniqueOrThrow({
    where: {
      id: 1,
    },
  });

  if (report.status === "open") {
    await tx.report.update({
      where: {
        id: 1,
      },
      data: {
        status: "closed",
      },
    });
  }
});

The previous code will fail and throw the following exception:

{
  "code": "P2028",
  "clientVersion": "4.16.1",
  "meta": {
    "error": "Transaction already closed: A query cannot be executed on an expired transaction. The timeout for this transaction was 5000 ms, however 5029 ms passed since the start of the transaction. Consider increasing the interactive transaction timeout or doing less work in the transaction."
  }
}

It appears that the Prisma client extension is attempting to insert audit log records using the base client (prisma) rather than the transaction client tx.

Can someone advise me on how to bind the Prisma client to the transaction instance?

I created the following repository to reproduce the error: https://github.com/babasbot/prisma-auditlog-extension-bug

Thanks! 🖖

[nurul3101]

Hello @babasbot 👋

There's a GitHub Issue which seems to be related to the issue you are facing:

• Client extensions in interactive transactions are bound to the base client #17948

But, the GitHub issue mentions that this is fixed in the latest prisma version. I can see that you are using 4.16.1, can you try using version 4.16.2 and check if the error still persists?

[nurul3101]

Please feel free to let us know in case you still need any assistance.

[captain-http]

Hey @nurul3101, apologies for the late reply. Unfortunately, your suggestion does not fix the issue.

Using the example that I provided, suppose the scenario where you have a single connection to the database, which is common practice in serverless environments. The await prisma.auditLog.create({ ... }) will hang until the transaction timeouts because the prisma instance is not running within the transaction (tx).

Note that increasing the timeout of the transaction will result in the transaction being stalled until the defined timeout period is reached since there are no other available connections.

The execution of the script will proceed as follows:

• The interactive transaction starts when await prisma.$transaction is called.
• await tx.report.findUniqueOrThrow gets called inside the transaction, invoking the client extension.
  • const result = await query(args) gets executed successfully. Note that it is running within the transaction.
  • await prisma.auditLog.create({ ... }); tries to insert an audit log entry, but it hangs until the transaction timeouts because it is not running within the transaction.
    • note that prisma instance is not bound to the transaction context as tx.

We have figured out a workaround, which is not optimal.

const _prisma = new PrismaClient(); // isolated instance

const auditLog = Prisma.defineExtension((prisma) =>
  prisma.$extends({
    name: "auditLog",
    query: {
      $allModels: {
        $allOperations: async ({ model, operation, args, query }) => {
          const result = await query(args);
          
          // instead of calling `prisma`, we are calling the `_prisma` instance
          await _prisma.auditLog.create({
            data: {
              model,
              operation,
              args: JSON.parse(JSON.stringify(args)),
            },
          });

          return result;
        },
      },
    },
  })
);

The script will execute successfully (even when only a single connection is available), but the audit trail instances won't be inserted within the transaction. As a result, audit trail records may still be inserted even if the transaction is rolled back, which is not desirable.

Is it feasible to make the client extensions aware of the transaction context? If not feasible, might be useful to document this limitation.

[tlingDeeded]

@nurul3101
Sorry for bringing up an old thread. I am also having problem with the exact same issue.

Specifically, for prisma client extension => query, there doesn't seem to be a way to make the client extension aware of the transaction context.

The issue you linked:

#17948

only addresses the issue when working with prisma client extension => client.

@babasbot 's hack works. But like he mentioned, it is not desirable.

[lewisblackburn]

Is there any update on this?

[f8k8]

I need to do something similar. Basically, when creating one model, I want to also create some default entries for another model. If the create is run in an extension, then I only have access to prisma, and not to the current transaction, so creating the other entries fails. I think I've found a really hacky workaround which involves accessing some of Prisma's internals, which obviously isn't ideal:

const prisma = new PrismaClient(clientOptions);
const extendedPrisma = prisma.$extends(
  Prisma.defineExtension((prisma) =>
    prisma.$extends({
      name: "customisations",
      query: {
        modelA: {
          async create(params) {
            const { args, query } = params;
            const result = await query(args);
            const transaction = (params as any).__internalParams.transaction;
            const context = transaction
              ? (prisma as any)._createItxClient(transaction)
              : prisma;

            context.modelB.create({
              data: {
                modelA: {
                  connect: {
                    id: result.id,
                  },
                },
                name: "A"
              },
            });

            return result;
          },
        },
      }
    })
  )
);

You lose any type safety, and it can break at any time if Prisma's internals change. Would it be a major change to pass the current transaction client in the parameters to the client extension? That way we can check if it's set and use that, or fall back to use prisma if there's no current transaction.

[ElYaiko]

I'm having the same problem for transaction with extensions, the only solution for now is adding a parameter to the function where you pass the current transaction variable so you can use the current PrismaClient in your method, ex:

prisma.user.$transacction(tx => { tx.user.myCustomMethod(tx); });

It would be good to support transactions also in extensions in a simpler way.

[ludralph]

Hi there,

To keep our discussions organized and focused on the most relevant topics, we’re reviewing and tidying up our backlog. As part of this process, we’re closing discussions that haven’t had any recent activity and appear to be outdated.

If this discussion is still important to you or unresolved, we’d love to hear from you! Feel free to reopen it or start a new one with updated details.

For more details about our priorities and vision for the future of Prisma ORM, check out our latest blog post: https://www.prisma.io/blog/prisma-orm-manifesto.

Thank you for your understanding and being part of the community!