A dashboard batches analytics events and flushes them with requestIdleCallback(flush). On a busy page the flush does not run for many seconds. Why does that happen, and how do you bound the delay?

## Why the flush never runs `requestIdleCallback` is a request for *leftover* main-thread time. The browser's turn looks roughly like: run a task from some task source, run any rendering steps that are due, and then, if the thread is free and the next frame is not yet needed, run idle callbacks until the idle period ends. Two properties of that arrangement explain the symptom. First, **idle callbacks are last in line.** Input handlers, timers, network responses, and the rendering steps all outrank them. On a dashboard that is receiving a stream of updates, each arriving payload creates a task, each task may dirty style and layout, and the frame after it consumes what was left. There is nothing after. Second, **nothing preempts a running task.** JavaScript on the main thread runs to completion. If a chart library spends 400 ms laying out a series, the browser cannot interrupt it to service a pending idle callback; the callback waits until that task ends and then waits again for an idle period that the *next* queued task may consume first. This is the sense in which "long tasks starve idle callbacks": it is not a fairness policy, it is the absence of any gap to run in. A third factor is worth naming even though it is not the cause here: a hidden or backgrounded page has aggressive throttling applied to deferred work, so a flush scheduled with no timeout in a tab the user has switched away from may be delayed far longer than anything you would observe while watching the page. ## The timeout option ```js requestIdleCallback(flush, { timeout: 2000 }); ``` `timeout` is the only option the API takes. It converts an opportunistic request into a bounded one: if no idle period has occurred by the time it expires, the browser queues the callback to run regardless of how busy the thread is. Inside the callback you can tell the difference: ```js function flush(deadline) { if (deadline.didTimeout) { sendSmallestUsefulBatch(); // no budget; do the minimum } else { while (deadline.timeRemaining() > 1 && pending.length) sendOne(); } } ``` On a timed-out invocation `timeRemaining()` is 0. The browser has explicitly chosen your callback over responsiveness, so the honest response is to keep it short. Treating a timed-out callback as if it had a normal budget is how a well-intentioned deferral turns into the long task that drops a frame. ## Choosing the timeout The timeout is a statement about how stale the work may become, not a performance knob. For analytics batching, a couple of seconds is typical — long enough that a quiet moment usually arrives first, short enough that a user who navigates away has not lost much. Setting it to a very small value defeats the purpose: nearly every invocation becomes a timed-out one, and you have written a worse `setTimeout`. Setting it to nothing at all is what produced the bug. ## What a timeout does not solve The timeout bounds *when the callback starts*, not whether the work survives. If the user navigates or closes the tab, a pending idle callback is simply dropped, and so is one that started but had queued a normal request. Deferred delivery of data that must not be lost is a different problem with a different platform answer, and the batching scheduler should not be asked to solve it. Nor does a timeout make the work cheap. A flush that serializes ten thousand events is a long task whenever it runs; the scheduling decision only controls *when* you pay, and the work itself still has to be small enough — or chunked across several callbacks — to fit the budget you are given. ## The diagnosis in an interview If you are shown this symptom, say the two things in order: idle callbacks run only in leftover time and cannot interrupt a running task, therefore a continuously busy thread yields no leftover time; and the platform's answer is the `timeout` option, whose arrival you detect with `didTimeout` and respond to by doing less. Then add the caveat that a page which never goes idle is itself the finding — persistent starvation means the main thread has no headroom, which is a problem with the page, not with the scheduler.