High permanent CPU usage after calling $disconnect on a client that executed an interactive transaction before (v3.9.0+)

[Valerionn]

Bug description

We often recreate our prisma client in automated tests. After each test, we call await prismaClient.$disconnect(). Starting with Prisma v3.9.0 (in Prisma v3.8.0 it works fine), this causes the node process to get very high CPU usage, stacking with each new client that disconnects, up to 100%.

After investigating the issue, I observed that this only seems to happen if the client was used to run an interactive transaction before (but it's not necessarily the last query).

How to reproduce

1. Have prisma in your project, enable the "interactiveTransactions" preview feature
2. Run the following script:

  let i = 0;
  while(true) {
    const x = new PrismaClient();
    console.log(++i);
    await x.$connect();
    await x.$transaction(async (prisma): Promise<void> => {
      console.log('Interactive transaction callback');
    });
    await new Promise(r => setTimeout(r, 5000));
    await x.$disconnect();
    console.log('Disconnected.');
    await new Promise(r => setTimeout(r, 5000));
    console.log('Launching next client...');
  }

The test script has pauses so you can observe the CPU usage - after "Interactive transaction callback" it's still fine, but as soon as "Disconnected" is displayed, the CPU usage of the node process increases tremendously and will stay on a high level (and will continue to increase as new clients call disconnect).

If you replace the interactive transaction with something different (e.g. a "normal" transaction), then the CPU usage will stay low.

Expected behavior

CPU usage should not skyrocket when disconnecting from a client after running an interactive transaction.

Prisma information

Environment & setup

• OS: Windows
• Database: PostgreSQL
• Node.js version: v16.13.1

Prisma Version

prisma                  : 3.11.0
@prisma/client          : 3.11.0
Current platform        : windows
Query Engine (Node-API) : libquery-engine b371888aaf8f51357c7457d836b86d12da91658b (at node_modules\@prisma\engines\query_engine-windows.dll.node)
Migration Engine        : migration-engine-cli b371888aaf8f51357c7457d836b86d12da91658b (at node_modules\@prisma\engines\migration-engine-windows.exe)
Introspection Engine    : introspection-core b371888aaf8f51357c7457d836b86d12da91658b (at node_modules\@prisma\engines\introspection-engine-windows.exe)
Format Binary           : prisma-fmt b371888aaf8f51357c7457d836b86d12da91658b (at node_modules\@prisma\engines\prisma-fmt-windows.exe)
Default Engines Hash    : b371888aaf8f51357c7457d836b86d12da91658b
Studio                  : 0.458.0
Preview Features        : interactiveTransactions

[garrensmith]

@Valerionn sorry for the really slow response on this. We think we have figured out the issue.
Could you run your tests or the test script with the following environmental variable set: CLOSED_TX_CLEANUP=0

[Valerionn]

@garrensmith I just tested it - running the test script with CLOSED_TX_CLEANUP=0 works correctly and the CPU usage does not rise when the environment variable is set to 0.

[garrensmith]

Great news. Thanks for confirming that for us. We will work on a better fix for that but in the meantime, you can use that workaround.

[Weakky]

Hey @Valerionn, we've just fixed the issue. It should be available in the next Prisma release (4.1.0).

Thanks for reporting 🙏