jest advanceTimersByTimeAsync hangs with fake timers: how to fix

Not specified by the original author.

TL;DR

advanceTimersByTimeAsync hangs when a promise the test awaits never resolves because the fake clock never reaches the timer that would resolve it, or when real-timer code runs inside the faked zone. Await the advancement itself, flush the microtask queue between steps, and make sure every timer in the chain is fake. Then the async work can actually complete.

Error

jest advanceTimersByTimeAsync hangs with fake timers: how to fix

The test hangs indefinitely at await jest.advanceTimersByTimeAsync(5000) with no error and no timeout.

Steps

1. Confirm fake timers are on before the hanging call: jest.useFakeTimers() must run before the code under test schedules anything. Expected output: modern fake timers confirmed active before any scheduling happens.
2. Await the advancement itself: await jest.advanceTimersByTimeAsync(1000) instead of calling it without await. Expected output: the test proceeds past the advancement instead of hanging.
3. Between advancements, flush microtasks with await Promise.resolve() so chained promises settle. Expected output: promise chains that were stuck now resolve.
4. Hunt for real-timer leaks: setImmediate, tight nextTick loops, and open handles like servers or watchers keep the test alive after timers are done; run with --detectOpenHandles. Expected output: the specific leak identified.
5. If the code mixes fake and real timing (for example a debounce plus a real network mock), fake only what you assert on and keep the rest real. Expected output: the test completes and still asserts the timing behavior.

When to use

• A test hangs after you switch to advanceTimersByTimeAsync.
• runAllTimersAsync never returns.
• Fake-timer tests hang only when awaiting real promises inside.

When not to use

• The test hangs with real timers (look for unresolved promises or open handles first).
• The hang is in beforeAll (timers may not be faked yet at that point).
• You are on legacy fake timers (advanceTimersByTimeAsync needs modern timers).

Variant phrasings

runAllTimersAsync never returns

An infinite timer loop (setInterval rescheduling itself) never exhausts; advance by fixed chunks with a loop bound instead.

Fake timers plus mocked network hang

Await the mock's promise resolution explicitly; fake timers do not advance real promise machinery.

Legacy versus modern fake timers

Modern timers fake Date and performance too; code reading the real clock under legacy fakes is a classic hang source. Prefer modern.

Why it happens

Fake timers replace the clock but not the promise queue. Async timer advancement still needs the microtask queue to drain for promises to resolve, and any timer scheduled on the real clock while the test waits on the fake clock creates a deadlock: each side waits for the other.

Edge cases

• jest.advanceTimersByTimeAsync advances macro-tasks only; a promise that awaits another promise in a loop can need several flush cycles.
• doNotFake lets you keep selected timers real; use it for the parts of the stack you do not want to control.
• A test that passes with --runInBand but hangs in parallel may be starving the microtask queue under worker load; treat it as a timing-sensitivity bug, not a Jest bug.

Provenance

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

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

Thread query: jest advanceTimersByTimeAsync hangs with fake timers: how to fix

TL;DR: advanceTimersByTimeAsync hangs when a promise the test awaits never resolves because the fake clock never reaches the timer that would resolve it, or when real-timer code runs inside the faked zone. Await the advancement itself, flush the microtask queue between steps, and make sure every timer in the chain is fake. Then the async work can actually complete.

Not specified by the original author.

TL;DR

After the Jest 27 upgrade, fake timers default to the modern implementation, whose API differs from the legacy one. Pass explicit options to jest.useFakeTimers, for example a doNotFake list for the pieces you need real, and set the system time with jest.setSystemTime. Most breakage is tests that relied on legacy quirks.

Problem

Tests that passed on legacy fake timers now fail or hang after upgrading to Jest 27 or later.

Steps

1. Find every jest.useFakeTimers() call with no arguments. Expected: you have the full list of affected tests.
2. Replace bare calls with explicit config, for example jest.useFakeTimers({ advanceTimers: true }) or a doNotFake list for timers you want real. Expected: timer behavior is explicit in each test.
3. Replace Date-mocking hacks with jest.setSystemTime inside the fake-timer block. Expected: Date.now() returns the mocked time.
4. Run the suite. Expected: previously hanging tests complete and time-based assertions pass.
5. If a legacy-only library truly cannot work with modern timers, set timers to 'legacy' in Jest config as a last resort. Expected: old behavior returns; plan the migration anyway.

When to use

• Upgrading Jest 26 to 27+ broke timer-dependent tests.
• jest.advanceTimersByTime seems to do nothing, or promises never resolve.
• Date.now() is not mocked the way the old tests assumed.

When not to use

• You are still on Jest 26 or below; legacy is the default there.
• The failure is a real timeout, not a timer-mock issue.
• You use Vitest; its vi.useFakeTimers has its own API.

Tool compatibility

• Jest 27, 28, 29, 30: modern timers are the default; config key timers accepts 'modern' or 'legacy'.
• jest.useFakeTimers(options) supports advanceTimers, doNotFake, now, and timerLimit.

Variant phrasings

jest modern fake timers not advancing

Usually a missing advanceTimers option, or awaiting a real promise inside fake time; make the config explicit.

jest.useFakeTimers broke Date mocking

Use jest.setSystemTime; modern timers fake Date by default, so manual Date stubs now conflict.

Why it happens

Legacy timers replaced timer functions with simple mocks that had loose semantics. Modern timers use a fuller fake-clock implementation with stricter, more correct behavior, so tests written against legacy quirks break.

Edge cases

• doNotFake with nextTick and setImmediate keeps promise-heavy code moving while timers stay fake.
• performance.now() is faked too; animation-frame style tests need it unfaked or advanced manually.
• Mixing real network calls with fake timers hangs; unfake or mock the network layer.

Provenance

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

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

Thread query: jest fake timers broke after upgrade to modern timers

TL;DR: After the Jest 27 upgrade, fake timers default to the modern implementation, whose API differs from the legacy one. Pass explicit options to jest.useFakeTimers, for example a doNotFake list for the pieces you need real, and set the system time with jest.setSystemTime. Most breakage is tests that relied on legacy quirks.

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.