`serializeQueryArgs` + `merge` combo does not allow actually fetching new data

[markerikson]

Pasting from #2620 (reply in thread) , discussion with @gordon-eliel :

The sandbox at https://codesandbox.io/s/merge-query-sandbox-4fmws8?file=/src/Pokemons.tsx has serializeQueryArgs + merge on the same endpoint, but it doesn't actually fetch more data when you change the page.

If you look at https://app.replay.io/recording/rtk-190-alpha-merge-pagination-not-refetching--13800b41-6680-402f-a564-a80a280a74d7?point=9735556619499725871884967098715939&time=4275&hasFrames=false , you can see what's happening:

• The query hook does see a new stableArg value, and dispatches initiate() again
• This does execute queryThunk...
• but the condition check inside of queryThunk ends up retrieving the existing cache entry for the same cache key, sees that it's already in a "fulfilled" status, and bails out without trying to fetch the data.

That makes sense, conceptually. The question is what to do about it.

Here's the current condition logic for reference:

    condition(arg, { getState }) {
      const state = getState()
      const requestState = state[reducerPath]?.queries?.[arg.queryCacheKey]
      const fulfilledVal = requestState?.fulfilledTimeStamp

      // Order of these checks matters.
      // In order for `upsertQueryData` to successfully run while an existing request is in flight,
      /// we have to check for that first, otherwise `queryThunk` will bail out and not run at all.
      if (isUpsertQuery(arg)) return true

      // Don't retry a request that's currently in-flight
      if (requestState?.status === 'pending') return false

      // if this is forced, continue
      if (isForcedQuery(arg, state)) return true

      // Pull from the cache unless we explicitly force refetch or qualify based on time
      if (fulfilledVal)
        // Value is cached and we didn't specify to refresh, skip it.
        return false

      return true
    },

The question is what to do about this. Should we mark it as "forced" if the stableArg has changed or something?

[phryneas]

And this is where I believe #2663 could come in.

[markerikson]

Yep, and fixed via that PR