RKT and ETag/If-None-Match cache validations

[mharj]

I have been playing with custom BaseQueryFn and hook other state to keep track query on queryCacheKey API ETags.
But eventually this fails on problem on Query Function as I actually need to return data payload which causes store event. (and need to maintain two separate states)
On normal fetch API actions this is simple one, just store etag to somewhere and on next query call use this, if fetch 304 no state update needed.
Problem doing this more manually is that when having a lot of endpoints this start to be bit heavy to maintain (or having more wrappers for state and API client).
So any ideas if there is way to hack this on RKT as it would be nice to have proper ETag based cache validations and also hook ETag based conflicts on mutate.

[mg1986jp]

For ETag-based cache validation with RTK Query, the trick is to handle the 304 response in your baseQuery and return the cached data without triggering a store update.

In your custom baseQuery, you can check if the response is 304 and return the previous result from the cache. Something like:

const baseQuery: BaseQueryFn = async (args, api, extraOptions) => {
  const etag = getStoredETag(args.url);
  const headers = etag ? { 'If-None-Match': etag } : {};
  
  const result = await fetchBaseQuery({ baseUrl: '/api', headers })(args, api, extraOptions);
  
  if (result.meta?.response?.status === 304) {
    // Return previous cached data — RTK Query sees no change, no re-render
    return { data: api.getState().api.queries[api.queryCacheKey]?.data };
  }
  
  // Store new ETag
  const newEtag = result.meta?.response?.headers.get('etag');
  if (newEtag) storeETag(args.url, newEtag);
  
  return result;
};

The key insight is that returning the same data reference means RTK Query's structural sharing will detect no change and skip the re-render.