You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The interval then continues to fire forever (since it is an interval after all, being used as if it were a timeout), throwing the same Error infinitely.
This shouldn't be possible anyway because closing the subscription should be done via unsubscribe, which will clear the interval. There's probably a separate bug or a problem on my end that results in this weird state happening. However, its probably still sensible to cover the inf loop purely from a logic point of view even if you think it shouldn't ever be hit.
Expected behavior
A few less infinite loops
Reproduction code
No response
Reproduction URL
No response
Version
latest (exists in 7 & 8)
Environment
No response
Additional context
No response
The text was updated successfully, but these errors were encountered:
Describe the bug
AsyncAction
usessetInterval
for delays, likely due to the factsetTimeout
is often throttled/less accurate.So the flow seems to roughly be this:
schedule(state, delay)
setInterval
is now created to fire indelay
timedelay
time passesexecute
is calledclearInterval
is called (via the recycle method)If the action is closed when we call
schedule
, nothing will happen as you can see here:rxjs/src/internal/scheduler/AsyncAction.ts
Lines 21 to 23 in 630d2b0
However, if the action is closed while we're waiting for
delay
time to pass, we will hit this:rxjs/src/internal/scheduler/AsyncAction.ts
Lines 90 to 92 in 630d2b0
This means we throw and never clear the interval.
The interval then continues to fire forever (since it is an interval after all, being used as if it were a timeout), throwing the same
Error
infinitely.This shouldn't be possible anyway because closing the subscription should be done via
unsubscribe
, which will clear the interval. There's probably a separate bug or a problem on my end that results in this weird state happening. However, its probably still sensible to cover the inf loop purely from a logic point of view even if you think it shouldn't ever be hit.Expected behavior
A few less infinite loops
Reproduction code
No response
Reproduction URL
No response
Version
latest (exists in 7 & 8)
Environment
No response
Additional context
No response
The text was updated successfully, but these errors were encountered: