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
RxJS version:
6.0.0-uncanny-rc.7 (probably present since 6.0.0-alpha.1
Code to reproduce:
We ran into it by using an internal property:
import{asapScheduler}from'rxjs';
...
if(asapScheduler.scheduled){// Not reaching this line if `scheduled === 0`.}
Additional information:
The internal implementation of setImmediate()returns a zero handleId the first time it is called. Although there is no official spec for setImmediate(), one would expect that the returned value would be similar to those of setTimeout() and setInterval(), which are both non-zero positive integers.
Furthermore, the return value is used by AsapScheduler's AsapAction, which checks it for truthy-ness and "re-schedules" with setImmediate() if it is falsy (e.g. 0).
I am not sure if this can actually break something.
We were bitten by it in angular.io, because we were using the internal scheduled property (which is assigned the handleId returned by setImmediate()) and checking it for truthy-ness. It is easy for us to work-around, but bringing it up in case it might actually break something (by calling setImmediate() more then once).
The text was updated successfully, but these errors were encountered:
RxJS version:
6.0.0-uncanny-rc.7 (probably present since
6.0.0-alpha.1
Code to reproduce:
We ran into it by using an internal property:
Additional information:
The internal implementation of
setImmediate()
returns a zero handleId the first time it is called. Although there is no official spec forsetImmediate()
, one would expect that the returned value would be similar to those ofsetTimeout()
andsetInterval()
, which are both non-zero positive integers.Furthermore, the return value is used by
AsapScheduler
's AsapAction, which checks it for truthy-ness and "re-schedules" withsetImmediate()
if it is falsy (e.g.0
).This seems to have been broken in 5eb6af7.
I am not sure if this can actually break something.
We were bitten by it in angular.io, because we were using the internal
scheduled
property (which is assigned thehandleId
returned bysetImmediate()
) and checking it for truthy-ness. It is easy for us to work-around, but bringing it up in case it might actually break something (by callingsetImmediate()
more then once).The text was updated successfully, but these errors were encountered: