Open SimenB opened 2 years ago
Pushed a commit that's almost there - interval
fails since the timer itself doesn't have an error object - only the last one does. Not sure how to deal with it? A single interval will run forever with runAll
without us ever registering an error
@fatso83 I don't know how to deal with setInterval
. Ideas?
One quick fix is of course to handle error
not being present in getInfiniteLoopError
and just return the error created there without trying to get a better trace
Pushed that latest thing - not ideal, but I don't know how to solve it properly
This looks fine, but TBH I am just too tired to grok the details of this right now, so I cannot really say something very useful about the .error
prop ...
All modified and coverable lines are covered by tests :white_check_mark:
Comparison is base (
85463d9
) 94.10% compared to head (61cfb60
) 94.10%. Report is 97 commits behind head on main.
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
Is this going somewhere? Can I help? Not totally sure what to do between your last commend and Benji's approval.
Purpose (TL;DR) - mandatory
Failing test from https://github.com/sinonjs/fake-timers/pull/375#issuecomment-919976426.
By not resetting, the counter is not tied to a specific clock but rather then entire
withGlobal
.I'll push a second commit moving the attribute from living in the
withGlobal
closure to living on theclock
object, which I think is more correct