drops later execution after sleep
See original GitHub issueHi, we’re seeing that some later invocations aren’t executed on schedule after a system comes back from sleep.
The system has a long running later
(every ~15min = 900000ms). After the system comes back from sleep, it triggers (caused by a failing network request) a 4s later execution which sometimes isn’t getting executed.
To debug the issue, we start a regular setTimeout in parallel to the later execution.
The setTimeout callback gets called 4s after executing it (see [global]
).
The later
execution looks like this:
now + wait = 1539002635660
- which is the same time the native setTimeout gets executed (~ Mon Oct 08 2018 14:43:55 GMT+0200 (Central European Summer Time))
https://github.com/BackburnerJS/backburner.js/blob/master/lib/index.ts#L646
- timers length is not 0 and searchTimer returns 6
- this means
_reinstallTimerTimeout
isn’t called
- this means
https://github.com/BackburnerJS/backburner.js/blob/master/lib/index.ts#L654
From the looks of it, this means that the scheduled timer isn’t registered, which means it won’t execute on time.
In the screenshot, we see the ember concurrency timeout
never yields in the 4000
case (no [concurrency] executing later cb 4000
logged).
My guess is that it isn’t scheduled and the next timer that triggers is the longer running one.
Issue Analytics
- State:
- Created 5 years ago
- Comments:8 (3 by maintainers)
Top GitHub Comments
Your cheap solution would not work if it immediately goes to sleep, and wakes up slightly before the
executeAt
, and install the new timer. In that case it could still have to wait ~15 min to fire.I just checked in Chrome and Safari for Mac, and they behave in the same way (pausing timeouts during system sleep). This is unfortunate.
I think the only reliable solution, is to reinstall the timer on each call to
_later()
. While this might look a bit weird on the already scheduled timers, it will ensure that new timers are handled properly.