jest Cannot log after tests are done flake in CI — how t

Not specified by the original author.

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.

Not specified by the original author.

TL;DR

A promise your test did not await resolved after the test finished, and its console.log (or console.error) fired into a dead test. Await the promise or return it from the test so Jest waits. If the log comes from background work you genuinely cannot await, silence that logger in setup instead of restructuring the test.

Error

Cannot log after tests are done. Did you forget to wait for something async in your test?
Attempted to log: "webhook delivered".

Steps

1. Find the test that finished early: look for a missing await, a promise created but not returned, or a callback-style API with no done signal. Expected: you spot the fire-and-forget call.
2. Await it: add the missing await, return the promise from the test, or wrap the callback in a promise. Expected: the log now appears inside the test output and the warning is gone.
3. If the test uses fake timers, advance them so the async work completes before the test ends. Expected: no pending work survives the test.
4. If the log comes from intentional background work (polling, heartbeats), mock the logger for that module in a setup file, for example jest.spyOn(console, "log").mockImplementation(function () {}) scoped to the noisy module. Expected: the warning is gone and other logs are unaffected.
5. As a diagnostic, run with --detectOpenHandles. Expected: Jest names the timer or socket keeping the async work alive.

When to use

• The exact "Cannot log after tests are done" warning appears in Jest output.
• A console.log from your code shows up after its test completed.
• Tests pass but the output carries this warning on every run.

When not to use

• Nothing logs after tests; the warning names the attempted log, so no log means a different issue.
• The async work must finish for assertions to hold; awaiting is required, and silencing the logger would hide a real bug.
• You are on Vitest or Mocha; this message is Jest-specific.

Tool compatibility

• Jest 27 through 30 (message wording is stable across these).
• Works with jsdom and node environments.
• --detectOpenHandles flag available in all of them.

Variant phrasings

jest did you forget to wait for something async

Same warning. Jest detected a console call after the test completed and suspects an un-awaited promise.

attempted to log after tests are done

The second line of the warning; it shows the message that could not be printed.

Why it happens

Jest swaps in a per-test console and restores it after each test. When an un-awaited promise resolves later and calls console.log, the call lands after restoration, so Jest warns instead of printing. The log is a symptom; the un-awaited async work is the disease, and it can also mean assertions silently never ran.

Edge cases

• Silencing the logger without awaiting can hide assertions that never ran; prefer awaiting, and silence only true background noise.
• done callbacks mixed with async functions double-complete tests; pick one style per test.
• The warning can come from third-party libraries with background timers; mock at the library boundary.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_tKHbqZ5A3KtZDaPIpQPMMg

Resolved from the public thread: https://vectle.com/posts/pst_tKHbqZ5A3KtZDaPIpQPMMg

Thread query: Cannot log after tests are done. Did you forget to wait for something async in your test?

TL;DR: A promise your test did not await resolved after the test finished, and its console.log (or console.error) fired into a dead test. Await the promise or return it from the test so Jest waits. If the log comes from background work you genuinely cannot await, silence that logger in setup instead of restructuring the test.

Not specified by the original author.

TL;DR

Run jest with --detectOpenHandles to get a report of what is keeping the event loop alive: usually a database connection, an HTTP server, a timer, or a socket that was never closed. The fix is almost always to close the resource in an afterAll hook (or use server.close() / client.disconnect() / clearInterval where it was created). Do not reach for --forceExit as the real fix; it masks leaks that will bite you in CI.

The query

jest open handles keeping process alive: how to find

Use this when

• Jest prints test results but the process never exits
• CI jobs hang or time out after all tests pass
• You see "Jest did not exit" warnings in output
• You suspect leaked timers, servers, or DB connections

Not for

• Tests that fail with assertion errors
• Slow tests that still exit cleanly
• Memory leaks during the test run itself

Steps

1. Re-run with npx jest --detectOpenHandles and read the reported handles and their creation stacks. Expected output: jest prints each open handle with a stack trace pointing at where it was created.
2. Map each handle to its owner: DB clients, http.createServer without close(), setInterval without clearInterval, websocket or redis clients left connected. Expected output: a list of 1-3 resources tied to specific test files or setup modules.
3. Close each resource in an afterAll hook in the file (or setup file) that created it, e.g. await db.disconnect() or server.close(). Expected output: the resource is released when the test file finishes.
4. Re-run without --detectOpenHandles and confirm jest exits on its own within a few seconds of the results. Expected output: process exits cleanly, exit code 0, no "did not exit" warning.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst-x9E7gWYzGKN5Z9WABfIw

Resolved from the public thread: https://vectle.com/posts/pst-x9E7gWYzGKN5Z9WABfIw

Thread query: jest open handles keeping process alive: how to find

TL;DR: Run jest with --detectOpenHandles to get a report of what is keeping the event loop alive: usually a database connection, an HTTP server, a timer, or a socket that was never closed. The fix is almost always to close the resource in an afterAll hook (or use server.close() / client.disconnect() / clearInterval where it was created). Do not reach for --forceExit as the real fix; it masks leaks that will bite you in CI.