calling runAllTimers after using Lodash's _.debounce results in an infinite recursion error

[rimunroe]

Do you want to request a feature or report a bug?

bug

What is the current behavior?

When using fake timers, creating a debounced function, calling it a couple times, and then calling jest.runAllTimers, an error will be printed:

Ran 100000 timers, and there are still more! Assuming we've hit an infinite recursion and bailing out...

  at FakeTimers.runAllTimers (node_modules/jest-util/build/FakeTimers.js:207:13)
  at Object.<anonymous> (__tests__/lodash-bug-test.js:12:8)

It seems that changing the second argument passed to debounce (the time in milliseconds to debounce the function for) changes whether or not this error occurs. For example: on my machine (mid-2014 MBP) it appears to always throw when the delay is above ~600ms, but only fails some of the time when it's around 500ms.

This issue has been encountered before (lodash/lodash#2893), and it seems to have been on Lodash's end. I added a comment to the issue in the Lodash repo, but @jdalton said that he's not sure why it would still be occurring with recent versions of Lodash.

If the current behavior is a bug, please provide the steps to reproduce and either a repl.it demo through https://repl.it/languages/jest or a minimal repository on GitHub that we can yarn install and yarn test.

https://github.com/rimunroe/lodash-jest-timer-issue

What is the expected behavior?

The calling jest.runAllTimers should cause the debounced function to behave as though the time it was told to debounce for elapsed.

Please provide your exact Jest configuration and mention your Jest, node, yarn/npm version and operating system.

I'm using macOS 10.12.4

No configuration other than calling jest.runAllTimers in the test.

I encountered the bug with the following versions:

• [email protected] with [email protected]
• [email protected] with [email protected] and [email protected]
• [email protected]
• [email protected]
• [email protected]

[thymikee]

Btw, I hit this too. Turns out lodash's implementation of throttle is way more complex than it (imo) should be. Ended up with a simple helper like this one because I didn't have time to debug what's wrong.

[jdalton]

Lodash throttles by way of debounce. It's robust and handles things like clock drift after daylights savings time. That said, IMO it's not really Lodash's burden to prop up a mock library. We do our part to be good neighbors and don't hold on to timer references like setTimeout. Beyond that it really depends on your level of mock. For example, you could mock the debounced function itself instead of the underlying timer apis.

[thymikee]

@jdalton thanks for your input!

[jdalton]

Since this is a recursive issue you might look into a non-recursive mock that uses a while loop and a queue array of setTimeout invocations to walk through. I've done something similar in the past when mocking out setTimeout to be a synchronous queue.

[taystack]

@rimunroe I had the same error when using jest.runAllTimers(). I switched to jest.runOnlyPendingTimers() and this fixed my problem.

[hasLandon]

jest.runOnlyPendingTimers() eliminates the error message for me, but the method is never invoked.

[alexandru-calinoiu]

I have the same issue, no error message but the method is not invoked.

[jkaipr]

Managed to work around this with a combination of jest.useRealTimers(), setTimeout and done.

  it('debounces the prop', done => {
    wrapper.prop('debounced')('arg1', 'arg2');
    wrapper.prop('debounced')('arg3', 'arg4');
    wrapper.prop('debounced')('arg5', 'arg6');
    setTimeout(() => {
      expect(props.debounced.calls.count()).toBe(1);
      expect(props.debounced).toHaveBeenCalledWith('arg5', 'arg6');
      done();
    }, 1000);
  });

[skray]

I am having this same issue. Using sinon's fake timers I am able to advance the clock and test that a debounced function is called. I am trying to convert to Jest, and using Jest's fake timers, I get Ran 100000 timers, and there are still more! when using jest.runAllTimers, and the function is not invoked when using jest.runOnlyPendingTimers or jest.runTimersToTime.

I am able to use real timers and do something similar to @jkaipr above:

it('triggers debounce', (done) => {
  //set up and call debounced function

  setTimeout(() => {
    //test function was called
    done()
  }, 300 /* however long my debounce is */)
})

[alecklandgraf]

I was able to get around this by mocking lodash's debounce module

import debounce from 'lodash/debounce'
import { someFunction, someDebouncedFunction } from '../myModule';
jest.mock('lodash/debounce', () => jest.fn(fn => fn));

...

it('tests something', () => {
  debounce.mockClear();
  someFunction = jest.fn();

  someDebouncedFunction();

  expect(debounce).toHaveBeenCalledTimes(1);
  expect(someFunction).toHaveBeenCalledTimes(1);
});

[thymikee]

Since lodash doesn’t use timers for it’s denounce and throttle I assume this particular issue is not actionable from our side and should be closed.

[cameron-martin]

What do you mean by not using timers?

[jdalton]

@thymikee The issue is this.

[rimunroe]

That’s fine with me

[jdalton]

@thymikee

Since lodash doesn’t use timers for it’s denounce and throttle I assume this particular issue is not actionable from our side and should be closed.

What timers does Lodash not use?
Lodash uses setTimeout for debounce and throttle.

I'm guessing the issue with jest is it has a problem with mocking setTimeouts that themselves call setTimeout.

For those wanting alternative mocks you might look at sinon.js/lolex.

[thymikee]

@jdalton looks like I misunderstood what you wrote earlier, sorry about that 😅.
Fake timers support running recursive setTimeouts, but Jest bails out after 100000 calls. Although lodash may hit some edge case.

[SimenB]

Should we look into just integrating lolex instead of rolling our own fake timer implementation?

[jdalton]

@SimenB That would be rad!

[SimenB]

Opened up #5165 for it.

[rimunroe]

I shouldn't have closed this in the first place, so I'm reopening it.

[jakubsadura]

I had a case where I wanted to test component which used _.debounce in several places and I had to mock implementation of only one usage, I've done it in following way:

const originalDebounce = _.debounce;
jest.spyOn(_, 'debounce').mockImplementation((f, delay) => {
    // can also check if f === yourDebouncedFunction
    if (delay === constants.debounceTime) {
        return f;
    }
    return originalDebounce(f, delay);
});

Hope this will help someone

[tleunen]

I'm having the same issue with the 100,000 limit reached and I've found out that the lodash implementation of debounce is creating a ton of timers.
When debouncing a fn with a wait time of 500ms, I can see multiple timers with wait values of 498, then multiple 497 and so on... So I'm not especially surprised that we can reach 100k.

@jdalton is that expected that lodash creates so many timers?
It calls leadingEdge first, and then loop until 0 in timerExpired

[xevrem]

I used this to mock lodash's debounce, it works for most of my use cases:
place the following in __mocks__/lodash/debounce/index.js in your root project directory

export const debounce = jest.fn().mockImplementation((callback, timeout) => {
  let timeoutId = null;
  const debounced = jest.fn(()=>{
    window.clearTimeout(timeoutId);
    timeoutId = window.setTimeout(callback, timeout);
  });

  const cancel = jest.fn(()=>{
    window.clearTimeout(timeoutId);
  });

  debounced.cancel = cancel;
  return debounced;
});

export default debounce;

then just use it with jest's timer mocking and your tests should behave correctly. as always, extend as appropriate :)

[johnnypesola]

Thanks @xevrem! But the debounced function is not being passed the correct arguments, I suggest updating your example with this (accept and spread args):

const debounced = jest.fn((...args) => {
  window.clearTimeout(timeoutId);
  timeoutId = window.setTimeout(() => callback(...args), timeout);
});

[SimenB]

Merged a fix 1 day before the issue's 3 year anniversary 😅 Available in [email protected] via jest.useFakeTimers('modern'). next docs: https://jestjs.io/docs/en/next/jest-object#jestusefaketimersimplementation-modern--legacy

[zwbetz-gh]

Got it to work with sinonjs fake timers. Here's a small sample:

import FakeTimers from '@sinonjs/fake-timers';

let clock;

describe('some tests', () => {

  beforeEach(() => {
    clock = FakeTimers.createClock();
  });

  it('should do a thing', () => {
    const fakeWaitInMillis = 5000;

    // call func that uses debounce

    clock.setTimeout(() => {
      // expect func to be called after wait
    }, fakeWaitInMillis);
  });
  
});

[dsmmcken]

Another basic mock similar to @xevrem answer but with a mocked .flush() as well, in case you need that.

Also note if you are just importing the lodash.debounce the mock goes in __mocks__/lodash.debounce/index.js

const debounce = jest.fn().mockImplementation((callback, delay) => {
  let timer = null;
  let pendingArgs = null;

  const cancel = jest.fn(() => {
    if (timer) {
      clearTimeout(timer);
    }
    timer = null;
    pendingArgs = null;
  });

  const flush = jest.fn(() => {
    if (timer) {
      callback(...pendingArgs);
      cancel();
    }
  });

  const wrapped = (...args) => {
    cancel();

    pendingArgs = args;
    timer = setTimeout(flush, wrapped.delay);
  };

  wrapped.cancel = cancel;
  wrapped.flush = flush;
  wrapped.delay = delay;

  return wrapped;
});

export default debounce;

[SkipCat]

Got this error when using jest.runAllTimers() or jest.advanceTimersByTime(msToRun)

Switching to jest.runOnlyPendingTimers() like @taystack suggested fixed the problem for me and did not prevent the setTimeOuts in my code from being executed

I didn't need lodash mocks or jest.useFakeTimers('modern')

[JasonMore]

I removed the jest parts from the mock, as it was conflicting with jest.resetAllMocks

src/__mocks__/lodash/debounce/index.ts

const debounce = function MOCKED_debounce(callback, delay) {
  let timer = 0
  let pendingArgs

  const cancel = () => {
    if (timer) {
      clearTimeout(timer)
    }
    timer = 0
    pendingArgs = []
  }

  const flush = () => {
    if (timer) {
      callback(...pendingArgs)
      cancel()
    }
  }

  const wrapped = (...args) => {
    cancel()

    pendingArgs = args
    timer = setTimeout(flush, wrapped.delay)
  }

  wrapped.cancel = cancel
  wrapped.flush = flush
  wrapped.delay = delay

  return wrapped
}

export default debounce

[esslamben]

So whats the actual recommended way of dealing with this?

[SimenB]

#3465 (comment)

Modern timers will be the default in jest@27 (currently available as jest@next)

[esslamben]

Thanks for the reply @SimenB, seem to still run into the problem even with jest.useFakeTimers('modern'); so I've opt'd to just mock the lodash debounce function as I couldn't get it to work.

Would love to figure it out though as the point at which it fails it throws a nasty error with Ran 100000 timers, and there are still more! Assuming we've hit an infinite recursion and bailing out.... Think I have a pretty unique use case where the debounce function actually calls an async request which I'm awaiting by calling await waitFor(() => expect(apiFunc).toHaveBeenCalledTimes(1)); This never gets called but interestingly a log in the function calling the debounced version is logging so I'm sure its a timing issue with the test expecting a result.

For anybody wishing to mock it I used @alecklandgraf jest.mock('lodash/debounce', () => jest.fn(fn => fn));

[SimenB]

Please open up a new issue with a minimal reproduction if you're stilling having issues

[chestozo]

little addition to @xevrem version here
(adding args support):

export const debounce = jest.fn().mockImplementation((callback, timeout) => {
  let timeoutId = null;
  const debounced = jest.fn((...args)=>{
    window.clearTimeout(timeoutId);
    timeoutId = window.setTimeout(() => callback(...args), timeout);
  });

  const cancel = jest.fn(()=>{
    window.clearTimeout(timeoutId);
  });

  debounced.cancel = cancel;
  return debounced;
});

export default debounce;

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
Please note this issue tracker is not a help forum. We recommend using StackOverflow or our discord channel for questions.