RTK Query cache clears after browser tab is frozen/hidden (e.g. sleep or long inactivity)

[romancavry]

Hello everyone! I’d appreciate some help with this strange issue, which I can’t seem to reproduce via chrome://discards either.

It’s likely that when the browser goes offline or becomes inactive for a while, it transitions the tab into a frozen or hidden state. In this state, JS processes are paused, and React’s rendering behavior may also change. As a result, I suppose, RTK Query may detect that there are no active subscribers to certain queries and automatically unsubscribes, which causes the cached data to be cleared.

When the user returns to the tab, the page isn’t reloaded (so the tab state isn’t discarded or terminated), meaning the Redux store remains alive — but the cache is already empty, leading to an empty UI render.

Current behavior:

• After resuming from system sleep or long inactivity, previously visible data disappears.
• No errors appear in the console or network tab.
• The page does not reload, but cached query data is gone.
• Navigating to another menu item or section forces a reload, after which data reappears.

Steps to reproduce:

1. Open some page.
2. Confirm that query data is visible.
3. Put the computer to sleep (±20 minutes).
4. Wake the computer.
5. Without any further interaction, observe that the data disappears (no errors in requests or console).

Additional notes:

• The issue isn’t consistently reproducible.
• Might be related to how RTK Query handles inactive subscriptions during browser freeze/hidden states.

[markerikson]

Are there any cache-clearing actions dispatched in the Redux store?

[romancavry]

@markerikson No, only invalidating tags when network connection lost, it's not the case here.

[markerikson]

In theory, as long as there's active subscriptions, that data should stay in the store, and as long as those components are still mounted there won't have been any unsubscribe calls. I wouldn't expect that a frozen or background tab would cause any kind of unmounts, so at first glance I don't see any obvious causes that would force RTKQ to remove data from the cache.

I think I'd really need a repro to see what's going on here, but I also understand that's going to be tough to produce.