[web-console] Make status polling resilient to hiding the page#6079
[web-console] Make status polling resilient to hiding the page#6079Karakatiza666 merged 1 commit intomainfrom
Conversation
There was a problem hiding this comment.
this seems rather indiscriminate, it will catch all kinds of errors
There was a problem hiding this comment.
The only error that could occur here is related to attempting to clear the already cleared timer, so catch-all is fine
| } | ||
|
|
||
| export type ClosedIntervalOptions = { | ||
| /** Delay before the first invocation. Defaults to `periodMs`. */ |
There was a problem hiding this comment.
what is periodMs?
Why does this need a default?
There was a problem hiding this comment.
periodMs is a period with which a certain action is performed, it is passed as an argument to closedIntervalAction(). It is a way to have the first execution of the action be offset from the start of the loop, while keeping the same period for all the subsequent action callabcks
There was a problem hiding this comment.
what is "rejection handling"?
which caller are we talking about here?
There was a problem hiding this comment.
"Rejection handling" means catching any exceptions thrown. "Caller" is implied as whatever code that called closedIntervalAction() meaning this function, designed to only provide reliable callbacks on set interval, does not take on responsibility of handling/bubbling up exceptions that occur in the action to be repeated
github-merge-queue
Bot
removed this pull request from the merge queue due to failed status checks
github-merge-queue
Bot
removed this pull request from the merge queue due to failed status checks
Signed-off-by: Karakatiza666 <bulakh.96@gmail.com>
github-merge-queue
Bot
removed this pull request from the merge queue due to failed status checks
3 participants
Fix #5913
The problem was the default browser polling mechanism (setTimeout and setInterval) gets severely throttled when the page is hidden (e.g. user switches to another tab), or when it simply goes out of focus (if the action was requested on a certain timeout the browser can trigger the callback later than requested). When page was hidden for a long time a lot of polling requests got queued by the browser and then executed in quick succession when the user returned to the page; causing some requests to fail and causing toast errors and unexpected program state corruption.
The fix is two-fold:
worker-timersto make sure the requested timeouts used for polling logic get executed on schedule and do not get throttled by browsers in some scenarios;All uses of useInterval and closedIntervalAction play nicely with the changed semantics of not running the updates when the browser tab is hidden (not if it's simply out of focus)
Since they only fundamentally differ in the way they are used,
useInterval()now re-uses the more genericclosedIntervalAction().Tested: manually tested some features that require polling: pipeline performance metrics updates, checked periodic health, license and config requests are being sent; tested that the page behaves normally after leaving it for a long time and coming back. Added unit tests for the
closedIntervalActionprimitive that validate the behavior when the browser tab is returned to, and the cadence of callbacks after it