RTK-Query, server-side rendering, rehydration, and 404 errors

[azangru]

I am trying to use RTK-query with a custom implementation of server-side rendering, which roughly follows what Next is doing, namely first dispatch all relevant actions against the store, then wait until they complete, and then pass the store to the redux provider in order to render the page. The state of the store is serialised and sent to the client as a part of the html payload, where it is used as preloaded state (as described in redux docs).

I am currently discovering that if the queried data is missing from the server (which erroneously responds with a 400 error at the moment; something that'll be fixed), and if the state of the slice resulting from this query looks like this:

{
  "queries": {
    "genomeInfo(\"foo\")": {
      "status": "rejected",
      "endpointName": "genomeInfo",
      "requestId": "LUg3Hp-PSnJpty9KZO4Ag",
      "originalArgs": "foo",
      "startedTimeStamp": 1657705119898,
      "error": {
        "status": 400,
        "data": {
          "message": {
            "error": "Invalid Genome ID: foo"
          }
        }
      }
    }
  },
  "mutations": {},
  "provided": {},
  "subscriptions": {
    "genomeInfo(\"foo\")": {}
  },
  "config": {
    "online": true,
    "focused": true,
    "middlewareRegistered": false,
    "refetchOnFocus": false,
    "refetchOnReconnect": false,
    "refetchOnMountOrArgChange": false,
    "keepUnusedDataFor": 60,
    "reducerPath": "restApi"
  }

On the client, I am just taking the whole serialised redux state that arrives from the server, and using it as the preloadedState option passed to redux-toolkit's createStore.

But what I discovered was that when the page is finally rehydrated on the client, RTK query sends another request to the same endpoint that it did on the server. Meaning that it does not treat the state that arrived from the server as cache.

Is this expected? If yes, then what would be the correct way of making sure that RTK-Q on the client treats the query information that it received from the server as cache? Do I have to read the api slice data back from the serialized redux state, and explicitly dispatch it so that it is caught in the extractRehydrationInfo function?

I did read these two sections of the docs [1, 2], but am still confused.

[phryneas]

It treats it as cache. But if a RTK Query component mounts and the last state was an error state, it tries again.
But yes, you have to use extractRehydrationInfo generally or you will have subscriptions lingering forever.

[azangru]

But if a RTK Query component mounts and the last state was an error state, it tries again.

Out of curiosity, is there a way to manually override this behaviour, if desired? Not that it's important; but in this case the client can probably trust the 404 response status returned during the server fetch attempt.

[phryneas]

I'm afraid, but no. If that component would never fetch on it's own, you could also use useQuerySelector, but I'm not sure from the back of my mind if that data wouldn't be removed from the cache after a while if no useQuery would hold onto it.