Polling requests stop after Token Refresh in the "Data Export", "Bulk edit" аpps

There is a work around - by refreshing the screen the behavior returns to as expected.

Hi I did some additional tests with minimizing windows, for me the jobs continue to work after I reopen the page. So my previous comment was not confirmed in practice. Therefore, I suggest closing this issue, if there are no objections based the comment before last.

Tatsiana says that for her this was reproduced from time to time, but a simple page refresh helps, data is not lost and a redirect occurs to next steps.

Based on information from QA, their tabs are always collapsed after run when they work with big jobs. And Chrome do some throttling for such tabs

Chrome begins throttling timers as soon as a page is no longer visible (e.g., when a tab is hidden or the window is minimized).

• Immediate Throttling: Once your page goes to the background, Chrome clamps timers (setInterval, setTimeout) so that they run no more frequently than about once per second (i.e., a minimum delay of 1000 ms).

• Extended Background Periods: If a page remains hidden for an extended period (commonly around 5 minutes), Chrome may further restrict background activity—potentially suspending timers entirely by “freezing” the page.

How the throttling works

The throttling happens in stages:

Minimal throttling

This happens to timers that are scheduled when any of the following is true:

• The page is visible.

• The page has made noises in the past 30 seconds. This can be from any of the sound-making APIs, but a silent audio track doesn't count.

The timer isn't throttled, unless the requested timeout is less than 4ms, and the chain count is 5 or greater, in which case the timeout is set to 4ms. This isn't new; browsers have done this for many years.

Throttling

This happens to timers that are scheduled when minimal throttling doesn't apply, and any of the following is true:

• The chain count is less than 5.

• The page has been hidden for less than 5 minutes.

• WebRTC is in use. Specifically, there's an RTCPeerConnection with an 'open' RTCDataChannel or a 'live' MediaStreamTrack.

The browser will check timers in this group once per second. Because they're only checked once per second, timers with a similar timeout will batch together, consolidating the time the tab needs to run code. This isn't new either; browsers have been doing this to some extent for years.

But, this doesn't answer the question of why this only happens after the refresh token is called.

More information:

I was unable to reproduce this behavior after testing in Eureka environments. Incognito and non-incognito window, minimized or maximized browser, nothing brought results. An attempt to isolate this problem failed.

Here is an endless job that will be requested and never completed - ideal for testing. Leaving it for hours, after each refresh, the data request continues.

I suggest closing this problem, there is no way to isolate it, the browser is absolutely clean based on the screenshots attached by QA. The code that is responsible for long requests is absolutely normal, without any visible potential problems. In addition, if in some exceptional situations this happens, after reloading the page everything works fine and progress continues (based on info from QA team), the job will not be lost and the user will be redirected to the next steps upon its completion. I don't know what else we can do here.

cc

to provide further details.