New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

stubbing setImmediate by default leads to undesirable behavior #960

Closed
kevinburkeshyp opened this Issue Jan 6, 2016 · 4 comments

Comments

Projects
None yet
4 participants
@kevinburkeshyp
Copy link

kevinburkeshyp commented Jan 6, 2016

I noticed this while trying to figure out why stubbing the system time caused csv writing to fail. It turns out that library had a setImmediate call that was blocking: https://github.com/C2FO/fast-csv/blob/master/lib/extended.js#L18

It seems like there are a bunch of libraries that rely on setImmediate for innocuous things, and that faking setImmediate leads to unexpected behavior in all of them:

Maybe it's unreasonable to expect that stubbing the system time does not cause csv writing to fail? In this case it's particularly difficult to track down, because in Javascript you can't just hit ctrl+c and get a stack trace showing you what went wrong. It took about 90 minutes just to identify what part of the code was freezing, and then to understand why sinon was responsible.

I'm not sure what the fix should be, but it seems to be affecting a lot of libraries, and at least one of them responded by creating its own version of setImmediate that can't be mangled with.

If the answer is I should be calling useFakeTimers(0, "Date"), maybe that should be the default? Maybe that fits better with my/people's expectations of how the world behaves?

@kevinburkeshyp kevinburkeshyp changed the title stubbing setImmediate by default lead to undesirable behavior stubbing setImmediate by default leads to undesirable behavior Jan 6, 2016

@mroderick

This comment has been minimized.

Copy link
Member

mroderick commented Jan 7, 2016

I'm not sure what the fix should be, but it seems to be affecting a lot of libraries, and at least one of them responded by creating its own version of setImmediate that can't be mangled with.

That is the recommended solution for when you're using setTimeout, setImmediate for effect of getting a new call stack (and not for controlling time).

taylorhakes/promise-polyfill#15

@NealEhardt

This comment has been minimized.

Copy link

NealEhardt commented Feb 24, 2017

Yep, I just spent 90 minutes diagnosing and fixing this in a commercial codebase.

At the very least, the docs should mention that setImmediate will be faked.

@neocolmartin

This comment has been minimized.

Copy link

neocolmartin commented May 19, 2017

For future reference, this form of the function now allows you to specify which functions are faked:

var clock = sinon.useFakeTimers([now, ]prop1, prop2, ...);

Sets the clock start timestamp and names functions to fake.

Possible functions are setTimeout, clearTimeout, setInterval, clearInterval, setImmediate, clearImmediate and Date. Can also be called without the timestamp.

So this solved the problem for me when working with express:

clock = sinon.useFakeTimers(1495020000, 'Date');
@mroderick

This comment has been minimized.

Copy link
Member

mroderick commented May 27, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment