jest: --detectOpenHandles not showing any message even test not finished completely.

We have an issue template that requests reproduction steps - this report is missing that. Happy to reopen if one is provided

Running with jest --forceExit --detectOpenHandles seems to work as expected. But it seems like a hack…

@SimenB I have a repro for this:

import {createPool, sql} from 'slonik'

describe('open handles test', () => {
  const slonik = createPool(`postgresql://postgres:postgres@localhost:5432/postgres`, {
    maximumPoolSize: 1,
    minimumPoolSize: 1,
    idleTimeout: 1,
  })
  beforeAll(async () => {
    await slonik.query(sql`drop table if exists foo`)
    await slonik.query(sql`create table foo(id serial primary key, bar text)`)
    await slonik.query(sql`insert into foo(bar) values('one two three')`)
  })

  it('selects', async () => {
    const result = await slonik.one(sql`select * from foo`)
    expect(result).toMatchInlineSnapshot(`
      Object {
        "bar": "one two three",
        "id": 1,
      }
    `)
  })
})

to run the db I’m doing docker-compose up with this docker-compose.yaml:

version: '3'
services:
  postgres:
    image: postgres
    restart: always
    ports:
    - "5432:5432"
    volumes:
      - postgres:/var/lib/postgresql/data
volumes:
  postgres: 

dependencies "slonik": "^16.19.5", "jest": "^24.8.0"

When running with --detectOpenHandles it just hangs after all tests pass, but doesn’t report anything.

Issue in slonik: https://github.com/gajus/slonik/issues/63

edit: adding afterAll(() => new Promise(r => setTimeout(r, 0))) fixes this for me (jest exits after tests). Not sure why that would be, but it seems like a bug.

Running with jest --forceExit --detectOpenHandles seems to work as expected. But it seems like a hack…

THANKS! After three hours! This was exactly what I was looking for!

A proper reproduction we can pull down and run. I can almost guarantee anything that’s not git clone && yarn && yarn test (possibly with a docker run before test if it needs to connect to something, and npm is of course fine) will not be very helpful.

#6937 (comment) packaged up in a repository might work. #6937 (comment) doesn’t reproduce for me.

Note that I have an open PR that improves this (#9532), however it makes certain simpler caser worse. Need to figure out the correct balance. Probably some sort of heading saying which were collected in case it helps track down others. So more false positives, but also higher chance of not missing the ones that are real

@SimenB as requested: https://github.com/mmkal/jest-6937-repro

Requires yarn and docker-compose:

git clone https://github.com/mmkal/jest-6937-repro
cd jest-6973-repro
yarn
yarn test

More details/a workaround in readme which might help to figure out the root-cause.

@SimenB I can confirm the issue @mmkal is showcasing.

Experiencing the same issue here. Unfortunately, the workaround does not work for me. I have to use --forceExit

A proper reproduction we can pull down and run. I can almost guarantee anything that’s not git clone && yarn && yarn test (possibly with a docker run before test if it needs to connect to something, and npm is of course fine) will not be very helpful.

https://github.com/facebook/jest/issues/6937#issuecomment-500886506 packaged up in a repository might work. https://github.com/facebook/jest/issues/6937#issuecomment-562861333 doesn’t reproduce for me.

---

Note that I have an open PR that improves this (#9532), however it makes certain simpler caser worse. Need to figure out the correct balance. Probably some sort of heading saying which were collected in case it helps track down others. So more false positives, but also higher chance of not missing the ones that are real

I’m seeing this issue too, it seems to be something do with Apollo Cache for me, any help would be appreciated. It passes locally but not in my CI.

jest --forceExit seems to work fine for me but also seems like a hack while I ignore the real problem.