afterAll callback not called when using preload script

[IlyaSemenov]

What version of Bun is running?

0.7.2

What platform is your computer?

Darwin 22.5.0 arm64 arm

What steps can reproduce the bug?

bun add orchid-orm pqm
createdb test

Test file foo.test.ts:

import { test } from "bun:test"

import { db } from "./setup"

test("test", async () => {
	await db.$query`select 1`
})

Preload file setup.ts:

import { afterAll, beforeAll } from "bun:test"
import { orchidORM, testTransaction } from "orchid-orm"

export const db = orchidORM({ databaseURL: "postgres://user@localhost/test", log: true }, {})

beforeAll(async () => {
	console.log("before all")
	await testTransaction.start(db)
})

afterAll(async () => {
	console.log("after all")
	await testTransaction.close(db)
})

Run it with: bun test -r ./setup.ts foo.test.ts

What is the expected behavior?

The test passes. afterAll is called and at least prints to console.

What do you see instead?

afterAll is never called, the test runner hangs (probably due to open pg pool with active transaction):

bun test v0.7.2 (9574db35)

foo.test.ts:
before all
(9.8ms) BEGIN
(0.5ms) select 1
✓ test [0.74ms]
<--- here it hangs forever

Additional information

Everything works if the test and beforeAll/afterAll are in the single file foo.test.ts:

import { afterAll, beforeAll, test } from "bun:test"
import { orchidORM, testTransaction } from "orchid-orm"

const db = orchidORM({ databaseURL: "postgres://user@localhost/test", log: true }, {})

beforeAll(async () => {
	console.log("before all")
	await testTransaction.start(db)
})

afterAll(async () => {
	console.log("after all")
	await testTransaction.close(db)
})

test("test", async () => {
	await db.$query`select 1`
})

bun test v0.7.2 (9574db35)

foo.test.ts:
before all
(22.5ms) BEGIN
(1.5ms) select 1
✓ test [1.72ms]
after all
(3.9ms) ROLLBACK

 1 pass
 0 fail
Ran 1 tests across 1 files. [89.00ms]

[Th1nkK1D]

Found the same issue here on Bun 1.0.11 with both postgres.js and pg. Likely it has something to do with the Postgres connection that is still alive. A similar issue and workaround were reported to porsager/postgres#682

[masterT]

This seems fixed with Bun 1.0.13.

[Th1nkK1D]

This seems fixed with Bun 1.0.13.

Confirmed. Upgraded to 1.0.13 and the issue is fixed.