matchFulfilled is not fired for cached results

[tkharuk]

Hi! struggling with a following scenario a bit

• user clicks link 1 from the sidebar
• URL changes, RTK loads config data via getConfig
• extraReducers listens for getConfig.matchFulfilled and saves payload
  • also clears some non-BE but related to config state
• user clicks on link 2 from sidebar, everything works the same
• user pokes around, non-BE related shared state changes and is written to slice
• user clicks on link 1 again
• nothing happens because callback for getConfig.matchFulfilled in extraReducers is never fired

I would expect matchFulfilled to be triggered disregarding the source (either api or cache), or is this expected?
I could invalidate cache at some point, easiest done when user initiates a click on sidebar link I suppose.

also having a hard time finding relevant information 😿

[phryneas]

matchFulfilled is only fired when also a request has been made.
There are three ways a request can take:

• pending -> fulfilled
• pending -> rejected
• pending -> rejected because of a condition (action.meta.condition will be true - this is a cache hit)

[georgeiliadis91]

On a different computer right now, But here is a pseudo snippet,

switch(true):
 case setFilterA.match(action):
 case setFilterB.match(action):
 case setFilterC.match(action):
 case setFilterD.match(action):
    myapi.endpoints.myendpoint.initiate(valA,valB,valC,valD) 
    return next(action)
 case myapi.endpoints.myendpoint.matchFullfiled(action): 
   dispatchEvent('update array data', action.payload.data)
   return next(action)
 case myapi.endpoints.myendpoint.matchRejected(action): 
   // I need to check here if this was rejected because the request failed, 
   // or because there was a cache hit. I am basically duplicating my logic 
   // for a successfull response received
   
   if(there is a cache hit){
      // Need to get the cache key
      // Find the data and then proceed
    dispatchEvent('update array data', action.payload.data)
   }else{ 
     do error handling here
   }
     
   return next(action) 
   

I have a bunch of actions that both initiate a request inside the middleware, that request is expensive.
If I have a cached value of a given combination of said filters I would like to use the cached value, since it rarely changes.

But as is the first time, I have to get the fresh request on the matchFulfilled and the ones after on the rejected case.
Hope this is clear of what I am trying to do. If there is a better approach please let me know.

[markerikson]

Off the top of my head I'm not sure you're going to be able to do what you're looking for just based on the thunks.

createAsyncThunk is designed such that if the condition option callback returns false, it will dispatch the 'rejected' action. The action will indicate that it bailed out, but there's no reason given why it chose to do so - all it knows is that condition said "don't run the request".

For RTKQ's internal usage of createAsyncThunk, the logic looks like this:

  const queryThunk = createAsyncThunk<
    ThunkResult,
    QueryThunkArg,
    ThunkApiMetaConfig & { state: RootState<any, string, ReducerPath> }
  >(`${reducerPath}/executeQuery`, executeEndpoint, {
    getPendingMeta() {
      return { startedTimeStamp: Date.now(), [SHOULD_AUTOBATCH]: true }
    },
    condition(queryThunkArgs, { getState }) {
      const state = getState()

      const requestState =
        state[reducerPath]?.queries?.[queryThunkArgs.queryCacheKey]
      const fulfilledVal = requestState?.fulfilledTimeStamp
      const currentArg = queryThunkArgs.originalArgs
      const previousArg = requestState?.originalArgs
      const endpointDefinition =
        endpointDefinitions[queryThunkArgs.endpointName]

      // 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(queryThunkArgs)) {
        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(queryThunkArgs, state)) {
        return true
      }

      if (
        isQueryDefinition(endpointDefinition) &&
        endpointDefinition?.forceRefetch?.({
          currentArg,
          previousArg,
          endpointState: requestState,
          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
    },
    dispatchConditionRejection: true,
  })

We only hit that last case if you explicitly ended up dispatching the same thunk with the same args while there was an existing cache entry already fulfilled, and if that happens all the action shows is action.meta.condition: true. There's no reason shown.

That may be enough for your logic to decide "well, I guess that must have been a cache hit". Or it may not. You might have to also actually run the selector for that endpoint with the same args, find the cache entry, and check its fulfilled status.

[georgeiliadis91]

We only hit that last case if you explicitly ended up dispatching the same thunk with the same args while there was an existing cache entry already fulfilled, and if that happens all the action shows is action.meta.condition: true. There's no reason shown.

That may be enough for your logic to decide "well, I guess that must have been a cache hit". Or it may not. You might have to also actually run the selector for that endpoint with the same args, find the cache entry, and check its fulfilled status.

Yep, that was what I was planning to do, check the selector if there is a cache key present. It just feels bit funny that the cache hit is matched at the reject and not the fulfilled :/

Are there any plans to implement something like matchCachehit down the roadmap? Or even if it doesn't exist, do you believe it is a good idea?

Btw @markerikson, thank you for the replies so far! :)

[markerikson]

No plans, and no, I don't think it's a good idea.

[georgeiliadis91]

Thanks for the reply!