当我运行以下测试时：
afterAll(async () => {
await runDbBuild();
await pool.end();
});
describe("queries.newteetypes.select.all():", () => {
test("Test 1: object keys ", async () => {
const awaitedResponse = await queries.newteetypes.select.all();
expect(awaitedResponse).toStrictEqual(anticipatedResponse);
});
});
I get this error: Jest has detected the following 1 open handle potentially keeping Jest from exiting:
上面显示的代码在生产中工作得非常好。问题仅在于jest给我一个潜在的打开句柄警告。
我可以通过引入延迟来修复它setTimeout() and Promise，但这个位置让我感到困惑。这是解决方案（相同的代码，但在查询调用上方添加了一行）：
afterAll(async () => {
await runDbBuild();
await pool.end();
});
describe("queries.newteetypes.select.all():", () => {
test("Test 1: object keys ", async () => {
await new Promise((resolve) => setTimeout(() => resolve(), 2000)); // Putting a delay before the query solves the problem, but putting the delay after the query doesn't resolve it.
const awaitedResponse = await queries.newteetypes.select.all();
expect(awaitedResponse).toStrictEqual(anticipatedResponse);
});
});
这对我来说似乎非常违反直觉。最初我尝试将超时设置为afterAll()函数，但无论我将其包含在哪里都没有任何区别。然后我尝试将其放在查询调用之后，在test()功能，但这不起作用。当我把它放在before查询调用后，我停止收到错误。但为什么这会有所不同呢？
将您的“new Pool(...)”视为承诺并await for it:
async function createPool () {
return await new Pool({ connectionString })
}
您的发现setTimeout，让我尝试这个并获得相同的成功结果：
await process.nextTick(() => {})
把它放在我的前面connect()工作了。所以从那里我开始备份到“最早”的点，添加一个process.nextTick可以解决这个问题，并且似乎只需治疗即可解决new Pool(..)作为一个承诺。
也许矿池愿意在完全准备好在幕后跟踪客户之前就开始分发客户？这可能就是为什么额外的await前面解决了这个问题。
这可能与人们无法正确关闭客户端或池的原因有很大关系——因为池管理的某些内容被破坏了。例如：https://github.com/brianc/node-postgres/issues/2341 https://github.com/brianc/node-postgres/issues/2341