typeorm: Memory leak in jest when using `createConnection`

Issue type:

[ ] question [X] bug report [ ] feature request [ ] documentation issue

Database system/driver:

[ ] cordova [ ] mongodb [ ] mssql [ ] mysql / mariadb [ ] oracle [ ] postgres [ ] cockroachdb [X] sqlite [ ] sqljs [ ] react-native [ ] expo

TypeORM version:

[ ] latest [ ] @next [x] 0.2.25 (or put your version here)

Steps to reproduce or a small repository showing the problem:

Repository demonstrating the issue: https://github.com/brigalabs/typeorm-memoryleak

using the following test in /src/leak.test.ts:

import { createConnection } from "typeorm";

describe("leak detector", () => {
  it("test leak", async () => {
    let conn = await createConnection({
      name: "default",
      type: "sqlite",
      database: ":memory:",
      logging: false,
      entities: [],
    });

    await conn.close();
  });
});

the following command exposes a memory leak. I can create a repository if necessary

yarn node --expose-gc ./node_modules/jest/bin/jest.js --runInBand --logHeapUsage --detectLeaks src/leak.test.ts

yarn run v1.22.4
$ yarn node --expose-gc ./node_modules/jest/bin/jest.js --runInBand --logHeapUsage --detectLeaks src/leak.test.ts
 FAIL  src/leak.test.ts
  ● Test suite failed to run

    EXPERIMENTAL FEATURE!
    Your test suite is leaking memory. Please ensure all references are cleaned.

    There is a number of things that can leak memory:
      - Async operations that have not finished (e.g. fs.readFile).
      - Timers not properly mocked (e.g. setInterval, setTimeout).
      - Keeping references to the global scope.

      at onResult (node_modules/@jest/core/build/TestScheduler.js:188:18)

Note that you’ll need to install the weak-napi package to use the jest --detectLeaks parameter.

About this issue

Original URL
State: open
Created 4 years ago
Comments: 25 (13 by maintainers)

Most upvoted comments

I’m having the same issue. Any updates on this?

djoca on Jul 29, 2020

This is caused by a long.js WebAssembly usage and it should be fixed in Node 12 after v8 7.9.317.23-node.20. Thereforce you can use

global['WebAssembly'] = undefined;

in your setupFiles jest

FanAs on Jun 9, 2020

Hi @imnotjames ,

I’m not sure if your last message was passive/aggressive, so I’ll assume it’s not. If you look closely at my initial message, I’ve provided a complete self contain method to reproduce that is also very minimal. I hate to have to write this but, as of today, TypeORM is leaking memory. I can definitely understand that long lasting bugs can be frustrating to a contributor and I wish I could help (I tried many way to fix the issue, including your recommendation, but it does not go away and keep crashing my test suite after a few cycles).

I truly don’t believe closing this issue would not be doing typeORM a favor.

typehorror on Jul 6, 2021

@debrice have you had any luck finding the leak? I’m dealing with the same bug right now 😦

Sadly, I had to give up. I’ve stopped using typeorm and switch to Prisma. but today I’m pretty convinced that the issue is related to how jest maintain the connection (and objects) than typeorm itself.

The two solutions I had is either switch to Jasmine (I know it truly sucks but today I’m happy I did) or start mocking all typeorm calls in Jest.

The only final way out I can imagine would be having a flag in typeorm to prevent the creation of a connection pool (which I suspect is the issue here). Because Jest creates a whole app for every test, there is hardly anything you can do beside mocking typeorm.

typehorror on Dec 8, 2021

Is it on the roadmap to fix this leak in createConnection, or will it exist in perpetuity as a footgun and “bizarre feature?” We might consider documenting the behavior that in testing environments, use new Connection instead of createConnection due to memory leak potential.

Sort of! It’s on the roadmap to deprecate and remove createConnection.

imnotjames on Jul 7, 2021

Hi @FanAs ,

I’ve attempted your recommendation and it doesn’t seem to be resolving the memory leak. I’ve added your changes to the codebase. I’m running nodeJS v12.18.0

typehorror on Jun 11, 2020