Mismatch in usage of redux-persist with RTK-Query

[Navipro70]

Hello, first off thanks for library!

I have next question: how to use redux-persist with RTK-Query?

Persistence and Rehydration statement from RTK-Query page especially provide extractRehydrationInfo with example, nothing else
At that time Use with Redux-Persist statement says that we should blacklist all api instances from RTK-Query

Unit solutions from this two paragraphs, I haven't got a result, always saw an error or empty payload in REHYDRATE action.

But I found this sentence, where @phryneas said that REHYDRATE restores data without subscriptions. But when I log an action object on REHYDRATE, I saw the subscriptions array with object inside:
{"err": undefined, "key": "root-store", "payload": {"_persist": {"rehydrated": true, "version": 1}, "myApi": {"config": [Object], "mutations": [Object], "provided": [Object], "queries": [Object], "subscriptions": [Object]}}, "type": "persist/REHYDRATE"}

Should I ignore that log and fully rely on skip subscriptions mechanism (if it's exsists?), and also ignore passing apis reducerPathes into blacklist ?

[Navipro70]

If I correctly debug actions, we must not pass api to blacklist if we want to persist it, also subscriptions are not being persisted in extractRehydrationInfo. I think we should update documentation, because currently it's not accurate

[phryneas]

It's quite some time since I've written that up, so from the back of my mind:

• redux-persist should persist the api slice, but not restore it
• it should be part of the REHYDRATE action though, which gives extractRehydrationInfo a chance to extract that data and do the restoring of relevant parts itself.

[Navipro70]

Okey, maybe I'm still missing something. How can I get the behavior of first article? Is it correct to say that REHYDRATE intercepts redux-persist restore action, and pass it to extractRehydrationInfo, which do all work for restoring data? So in that case we should not pass api slices to blacklist redux persist config.

It's quite some time since I've written that up, so from the back of my mind:

• redux-persist should persist the api slice, but not restore it
• it should be part of the REHYDRATE action though, which gives extractRehydrationInfo a chance to extract that data and do the restoring of relevant parts itself.

[phryneas]

I'll be honest - I've written that primarily for SSR purposes.

It seemed like the feature should work with redux-persist from the source code of persist, and as we put out the alpha people reported it was working for them - but I've never tried it myself. And that was about a year ago, so I don't remember all details.

So I can't really tell you what they were exactly doing or if it actually worked :/

From taking a quick look at our sources: it should be fine for redux-persist to actually restore that data - the internal cacheCollection middleware should unsubscribe all subscriptions that were part of that data afterwards.