Skip to content
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
Closed

Comments

@kevinburkeshyp
Copy link

@kevinburkeshyp 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
Copy link
Member

@mroderick 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
Copy link

@NealEhardt 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
Copy link

@neocolmartin 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');
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants