Avoiding unbounded query subscription growth (and unnecessary cache invalidations)

[jpcody]

Notably, the following question is using RTK Query in the context of a React Native application.

We have a single screen that fetches and lists record. Users can filter those records via a modal, resulting in the following queries and subscribers after filtering data a few different ways:

• Subscriber 1 - Endpoint + Filter set 1 (stale)
• Subscriber 2 - Endpoint + Filter set 2 (stale)
• Subscriber N - Endpoint + Filter set N (current)

Upon navigating to an individual record (thus the list screen is still mounted in our navigation stack) and making a change, all N subscribers are immediately refetched. This results in unnecessary server load for data that's no longer relevant.

I'm surprised this isn't a more common problem, but maybe our issue is unique to the nature of navigating stacks in React Native.
Has anyone else solved this? Or do you perhaps have ideas on how we should avoid querying this stale data?

[phryneas]

You could probably do something like { skip: !useIsFocused() }.
Generally, it's a conceptual thing - your component is still mounted, so it still does things. It's time for React's offscreen api, or real component freezing.

[seanpcoyle]

To give further color on the issue that @jpcody is describing - we're seeing an issue where, throughout a screen/component's lifespan, we are calling a useQuery hook with changing query parameters based on a set of user selections, only one of which is the "current" set. Because the component remains mounted, subscriptions to previous sets remain active and are never wiped from cache. The user slowly accumulates subscriptions as they change their selection set.

Ultimately, when they perform a mutation that invalidates the cache key for this query, every still-mounted query re-fires, leading to a barrage of API requests.

Notably, the component isn't triggering the refetch, but rather the mechanism that re-fires invalidated subscriptions is re-fetching, thus, I don't believe a skip or skipToken would work here.

Is there a way for us to programmatically unsubscribe from the queries tied to the old query params?

The only idea I can think is to push the hook down into a component, then passing that component a key that's representative of the selection set, assuring that as the selections are changed, the component is remounted, thus removing existing subscriptions.

[phryneas]

That shouldn't be the case. If you just change a hooks query parameters, it will unsubscribe from the old result and subscribe to the new one. After 60 seconds, your old result will be removed from the cache, and invalidating it earlier will remove all unsubscribed ones and only refetch the subscribed ones.

[seanpcoyle]

That was my expectation as well. However, in this case, we noticed that our component (a React Navigation screen in this case) is holding on to all previous subscriptions indefinitely, long after the 60 second cache window has come and gone.

I'll dig further into our implementation and see if there's anything I've missed. If I can't find anything, I'll try coming up with a minimal reproducible example.

[seanpcoyle]

To close the loop on this - our queries were remaining subscribed due to the use of usePrefetch without fully understanding the nuance behind it, specifically the bit mentioned here: #1283. After yanking out our usePrefetch calls, RTK is back to behaving as one would expect it to.

@phryneas, thanks for jumping in here and replying. Your confirmation of our expectation on how the library should work helped us isolate the issue to our end.