Tag invalidation without subscribers

[andyl-ioki]

Hej there!

Here is a flow that I find confusing:

1. Component X subscribes to endpoint A.
2. Endpoint A fetches data from the backend.
3. Component X displays the data.
4. ...
5. Component X unsubscribes from endpoint A (subscriber count now hits 0).
6. The application gets notified by the backend that endpoint A has new data, so we trigger the tag invalidation for endpoint A.
7. Component X subscribes again to endpoint A.
8. Since the cached data is still there (we are within the keepUnusedDataFor time), the cached data is shown. 🤯

What I don't understand is why the cached data is used even though it was invalidated. So no re-fetch for invalidated data is done 😢.
Is this the proper behavior?
To me the behavior should be that the cached data is not used at all (fetching directly new data after step 7.).

[markerikson]

So no re-fetch for invalidated data is done 😢.

I don't understand this part - can you clarify? Is the question about whether a re-fetch is (or is not) occurring when a tag invalidation happens, or about the caching behavior?

Note that we designed RTKQ to keep the last successful request result as data, so you can keep showing the last valid values. That means that if there's a request in progress, you still have valid data to display.

[markerikson]

I did some digging through the code, and I think some of my understanding of the behavior was wrong. It looks like we remove a cache entry if the tag is invalidated and there are currently no subscribers:

    context.batch(() => {
      const valuesArray = Array.from(toInvalidate.values())
      for (const { queryCacheKey } of valuesArray) {
        const querySubState = state.queries[queryCacheKey]
        const subscriptionSubState =
          internalState.currentSubscriptions[queryCacheKey] ?? {}

        if (querySubState) {
          if (countObjectKeys(subscriptionSubState) === 0) {
            mwApi.dispatch(
              removeQueryResult({
                queryCacheKey: queryCacheKey as QueryCacheKey,
              }),
            )
          } else if (querySubState.status !== QueryStatus.uninitialized) {
            mwApi.dispatch(refetchQuery(querySubState))
          }
        }
      }
    })
    ```

[phryneas]

Yeah that's core behavior. If there are no subscribers, there is no telling if you ever will be interested in the data again, so it's not refetched, but removed instead, keepUnusedDataFor or not (as it definitely shouldn't be used wihout a new fetch in the future).

If you still see data... do you copy that over into hand-managed state somehow?

[andyl-ioki]

Can you show the actual code?

Sorry that I have confused you.

As an overview: Backend notifies us on updates on data via firebase listeners.
This listener then invalidates the appropriate tag and right after that we manually trigger the re-fetch with initiate.

So our firebase listener looks like this:

pokemonListener.on('value', (snapShot) => {
  // Some code here ...

  dispatch(invalidateTags(['pokemon']));
  dispatch(fetchPokemon());

  // Some more code ...
});

And here the fetchPokemon thunk:

export const fetchPokemon = (): Thunk => {
  return async (dispatch, getState) => {
    const getPokemonSubscription = dispatch(
      endpoints.getPokemon.initiate(undefined)
    );
    const { data, error } = await getPokemonSubscription;
    getPokemonSubscription.unsubscribe();

    // ...

    if (data) {
      // ...

      fetchPokemonSuccess(data);  // Reducer to save the `data` into redux manually, which is then used by components 
      
      // ...
    }
  }
}

And this is the redux slice:

const pokemonSlice = createSlice({
  initialState,
  name: 'pokemon',
  reducers: {
    fetchPokemonSuccess: (state, action: PayloadAction<PokemonState>) =>
      action.payload,
    // More reducers ...
  },
});

---

It looks like we remove a cache entry if the tag is invalidated and there are currently no subscribers

This behavior is fine for us.

Yeah that's core behavior. If there are no subscribers, there is no telling if you ever will be interested in the data again, so it's not refetched, but removed instead, keepUnusedDataFor or not (as it definitely shouldn't be used wihout a new fetch in the future).

Thanks for clarifying 👍

If you still see data... do you copy that over into hand-managed state somehow?

Yes, we save the data in redux manually. This is what fetchPokemonSuccess does.
We want to migrate away from this behavior and don't want to forward RTKQ results in redux manually anymore. Then we just want to use hooks instead.

---

Thanks again! I really appreciate your time and efforts!!

[andyl-ioki]

I think the problem what we have is, that we relied on the fact, that initiate waits for the re-fetch result. But as you stated and as I understood it, it may return the cached data 👍 So we would need additional logic to handle that waiting for the actual result here.

So we go into the direction to use the initiate part with forceRefetch.
Not the best solution, but it works for now.

We will remove the initiate code in the near future anyways and use hooks then. It's a lot easier.

Thanks for your help!