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.