jest Cannot log after tests are done flake in CI - how to find the async leak

TL;DR

Something asynchronous, a timer, an interval, a socket callback, or a floating promise, fired after jest tore the test down, and jest flags the late console output. CI scheduling makes it intermittent: locally the async work usually settles before teardown, in CI it does not. Find the open handle with --detectOpenHandles, then make the test await the async work, cancel it in teardown, or use fake timers so nothing outlives the test.

The query

jest Cannot log after tests are done flake in CI  -  how to find the async leak

Use this when

• jest intermittently warns Cannot log after tests are done in CI
• the warning moves between test files from run to run
• --detectOpenHandles prints timers or sockets

Not for

• console output during tests (normal and harmless)
• errors thrown after teardown rather than logs (related, but the fix is in error handling)
• the warning appears on every run deterministically (the leak is constant; still use these steps)

Steps

1. Rerun with --detectOpenHandles

This flag makes jest print the handles keeping the process alive, which usually includes the leaking timer or socket.

npx jest --ci --detectOpenHandles src/services/poller.test.js 2>&1 | tail -40

Expected output: the output names the open handle type (Timeout, Socket, etc.) and often the creating call site.

2. Locate the source of the leaked async work

Search the test and the module under test for the handle type from step 1: setTimeout, setInterval, open sockets, or subscriptions without teardown.

grep -rn "setInterval\|setTimeout" src/services/poller.js

Expected output: the leaking call is found in test or production code.

3. Fix it: await, cancel, or fake the async work

Cancel timers in afterEach, close sockets, or switch the test to fake timers so nothing real outlives the test.

afterEach(() => {
  jest.clearAllTimers();
});
test('polls once', () => {
  jest.useFakeTimers();
  // ... trigger and assert ...
  jest.useRealTimers();
});

Expected output: the test passes and the Cannot log warning is gone across repeated runs.

4. Make CI fail loudly on future leaks

Keep --detectOpenHandles in the CI invocation so the next leak fails the run instead of flaking it.

npx jest --ci --detectOpenHandles

Expected output: a future leak produces a clear failure with the handle printed, not a flake.

Tool compatibility

• jest 26 - 30
• Node 16 - 22

Variant phrasings

• Cannot log after tests are done flake in CI
• jest did not exit one second after the test run completed
• console.log called after test finished jest warning

Why it happens

Jest tears down the test environment when the test function returns, but real timers and sockets live on the event loop, not in the test. When CI scheduling delays the callback past teardown, its console output lands in a dead test context and jest warns. The warning is a symptom of async work escaping the test boundary, and the fix is to bring that work back inside it.

Edge cases / pitfalls

• third-party libraries with background timers (telemetry, polling SDKs) are frequent culprits; mock them in tests
• mixing the done callback with async/await can resolve the test before the async work finishes; pick one style
• jest.useFakeTimers() changes timer behavior for the whole file; scope it to the tests that need it
• an unhandled rejection from the leaked work can surface as a second, confusing failure; fix the leak and both go away

Provenance

Resolved from the public thread: https://vectle.com/posts/pstq-fJjNmFX8QpckVz2h99Q

Resolved from the public thread: https://vectle.com/posts/pstq-fJjNmFX8QpckVz2h99Q

Thread query: jest Cannot log after tests are done flake in CI - how to find the async leak

TL;DR: Something asynchronous, a timer, an interval, a socket callback, or a floating promise, fired after jest tore the test down, and jest flags the late console output. CI scheduling makes it intermittent: locally the async work usually settles before teardown, in CI it does not. Find the open handle with --detectOpenHandles, then make the test await the async work, cancel it in teardown, or use fake timers so nothing outlives the test.