RTKQ: Delayed invalidationBehavior issue with long running queries

[MateuszGroth]

Issue description

Whenever there is a pending query on some endpoint 'A', invalidation of cache (re-fetch when subscribed) on endpoint 'B' is only triggered when the endpoint 'A' query finishes.

Consider a scenario where you have two queries getPosts and getMyPosts. Let's assume that getPosts takes around 25 seconds to finish and getMyPosts returns data immediately (200ms).

Steps to reproduce:

• Subscribe to getPosts and getMyPosts
• invalidate getMyPosts after a couple of seconds (while getPosts query is still pending)

Expected result:

• my posts data is re-fetched right after the invalidation (delayed as a task/microTask)

Actual result:

• my posts data is re-fetched only when the getPosts query finishes

"@reduxjs/toolkit": "2.2.1",
"react-redux": "9.1.0",
"redux": "5.0.1"

[EskiMojo14]

yeah, this is a 2.0 change - you can set invalidationBehavior: 'immediate' to use the 1.9 behaviour.

[MateuszGroth]

@EskiMojo14 I get the idea behind the 'delayed' option as I also experienced issues with the 'immediate'. However, I feel like this is delayed a bit too much if you know what I mean. Why would the invalidation of a query wait for another query to finish loading?

[MateuszGroth]

I have some long-running queries in a production environment and can't do much about it. They kind of run in the background and are not blocking user actions with other parts of the UI. When the user does some actions that invalidate the tags of those immediate queries, they are not being re-fetched until this long-running one finishes loading. I know I can fix this case by changing to 'immediate' invalidationBehavior, but I really would like to find a solution that does not require that change

[markerikson]

I think there was some discussion in the original issue around possibly trying to make the behavior more targeted in which queries it waits for, but we opted to defer that aspect in order to get 2.0 out the door.

[BrenoVelasco]

Do we plan on adding support to an "ignore" feature? There are some long-running queries that we poll every X seconds and we'd love to be able to skipDelayInvalidation or something for these. Thanks!

[elburro1887]

I would also support an "ignore" feature, or a revert to the default value.

I just discovered that this is the reason why my caches were only sporadically updating, and I have been working with RTK Query for over a year.

I have a periodic query, which somehow was screwing up the cache updates because of this setting. I changed it to 'immediate' now, and everything works flawlessly, finally!

This flag is not documented in the Cache Docs (https://redux-toolkit.js.org/rtk-query/usage/cache-behavior) and I'm sure I'm not the only one that go tripped up by it, since there are a lot of questions and confusion about the cache behaviour on Stack Overflow and Reddit, etc..

Therefore I would argue that the default here is not a "smart" default, so I would recommend to change it back.

[markerikson]

@elburro1887 it's something we can consider, but changing that would have to wait until the next major.

Do you have any links to these other discussions you're referencing? I haven't been looking at SO much lately, but I don't remember seeing any relevant discussions on /r/reactjs or /r/reduxjs .

[elburro1887]

Thanks for the fast reply.
To be fair, I don't have any concrete links on hand, I just have my own anecdotal experience.
I was often looking for solutions online and (until now) never found anything concrete that would solve my issues, and from my feeling when reading lots of online material a lot of people seem to struggle with "unexpected" cache behavior.