redux-persist: Getting error redux-persist: rehydrate for "root" called after timeout

A workaround I’ve discovered for my own use: kill redux-persist’s timeout functionality. If the timeout hits, your store is rehydrated with the initial state and then persisted again to kill the state that is likely still loading.

In your persist config, prevent the timeout setup (persistReducer.js#L88-99):

const persistConfig: {
   ...
   timeout: 0, // The code base checks for falsy, so 0 disables
};

A complete solution for redux-persist would be to add a timeout component to PersistGate that would render if your timeout is hit and stop the rehydration work. What it shouldn’t do is then rehydrate your store with initialState, which is the current functionality.

try this

const persistConfig = { key: 'root', storage, timeout: null };

work for me

Delete the App Reinstall the App

Works for me.

I get this issue with 5.9.1. For me it only occurs when remote debugging.

Potentially related to this issue with setTimeout in React Native https://github.com/facebook/react-native/issues/4470

Adding timeout time of 10 seconds will work if you are using Debugger

const persistConfig = { timeout: 10000, key: ‘root’, storage, };

Tested on redux-persist: 5.10.0

I have the same problem. Setting timeout > 5s seems to fix it. timeout defaults to 5s. I set mine to 10s.

const persistConfig = {
    timeout: 10000,
    key: 'root',
    storage,
};

const persistedReducer = persistReducer(persistConfig, reducers);

Using redux-persist@5.9.1

I was getting the same error. The issue was the emulators date and time weren’t synchronised with my computer’s. Make sure your date and time is the same between both

apologize for the churn here, v5.7.2 resolves the issue.

tests missed the issue on 5.7.1 as it was a console.error, not an actual exception

@JanithaR npm install redux-persist@5.6.12 @avid21 good 😄

Got this error on v6 during remote debugging because my computer time was 1 hour behind. After fixing the time, the error was gone!

still happening with 5.10.0, it’s a bit weird because it happened after few mins working without issues

Same here I am also getting the same error in "redux-persist": "^5.10.0" in react-native. Please can someone help.

For me it was the short ‘debounce’ time which caused the error:

const persistOptions = {
  storage,
  debounce: 100, // <-- not working in 'Debug JS' mode
  key: DeviceInfo.getBundleId(),
  transforms: [compressor],
};

persistReducer(persistOptions, rootReducer)

I increased the time to 500 and now it’s working fine.

react-native: v0.53.0 redux-persist: 5.9.1

Ok, that fixed not the error. I downgraded to v5.7.2 v5.6.12 and now it’s working.

5.10 idem

I am stuck with this issue on my recently expo detached project. My state is never persisted regardless of remote debugging, and occasionally I get the error like the OP.

Expo: 24.0.0 react: 16.0.0 RN: Expo 24.0.0 fork react-redux: 5.0.7 redux: 3.7.2 redux-persist: 5.9.1

On an up note, thank you very much for your work!

@sytolk, Yes, I’m use the latest version and still have the error. This error only happens when I use the debug in the first time.

"redux-persist": {
      "version": "5.7.2",
      "resolved": "https://registry.npmjs.org/redux-persist/-/redux-persist-5.7.2.tgz",
      "integrity": "sha512-NgkSoPA3o6vAo09U5hnzO8CgHNhnBIcZyZBr+tRa/pDDeQqtcsP/zru9b2vz5tIpK6GCYGEsEjSzWUU/vxfRQA=="
    },

Yes, getting the same error. Reverting to 5.6.12 worked

Same problem to react-native 0.60.0

I also do encounter this error with redux-persist@5.10.0.

The error message I’m getting during the persist/REHYDRATE action is redux-persist: persist timed out for persist key "root".

As far as I understand, redux-persist internally uses RN’s AsyncStorage in order to store the state. Also, there is an issue when using AsyncStorage when debugging remotly, which makes the promise hang indefinitely (and may cause a timeout).

Could it be the reason why redux-persist fails to load the state?

“redux-persist”: “^5.9.1”

I’m having the same issues. Still no fix? Or hints? Or clues?

I was getting the same error on redux-persist version 5.9.1.

It was working fine until I put the whitelist prop into rootPersistConfig :

const rootPersistConfig = { key: 'root', ... , whitelist: ['auth'] };

But then I switched back to using the blacklist property and everything works fine now.

const rootPersistConfig = { key: 'root', ... , blacklist: ['navigation', 'isLoading', 'hasErrored'] };

@avid21 Reverting back to 5.6.12 worked for me.

Still happening with React Native version 0.60.0 and redux-persist 5.10.0.

I tried the suggestion with timeout being set to 0, not working at all.

@Avid21 Reverting back to 5.6.12 worked for me.

not working for me and 6.0.0 as well

Happened to me also with the latest version v5.10.0 on web version

Same issue: Android with Remote debugging on 5.9.1. Will try version 5.7.2.

Edit: 5.7.2 did not work, 5.6.12 looks ok.

I’m using version 5.9.1 , only show error when enable Remote JS Debugging. Still no solution?

@NichAga Yes, it should work. I was using Remote JS debugging. I stopped it and hence naturally it’s working now.

Still actual

This issue was been there for a while, i tried a lot fixing it and finally @Gustash solution resolves it, thank you very much 👍

try this

const persistConfig = { key: 'root', storage, timeout: null };

work for me

+1

So a good workaround for this is to use React Error Boundaries.

If there is an error thrown during the initial render that happens after rehydrate, then the timeout will be reached, and an additional rehydrate will fire that replaces all state with initial state. This results in catastrophic data loss, so doubtful that this is what you want. In a react-native environment, however, NOT doing this means your users will be stuck in a state where the app can’t ever start again.

By wrapping the component tree within PersistGate in an error boundary, you can prevent this from occurring by catching and handling the error, and presenting a fallback UI. It’s up to you what to do about the defective state tree that results in a crash on the initial render. In my case, I’ve elected to log the error and provide the user with a choice of submitting feedback and exiting the app (re-throwing an error) and waiting for help, or to clear their data and start from a fresh state. How this should be handled will be highly dependent on the particulars of your application.

I’ll provide a code snippet a bit later once I’ve finalized my own implementation of this, but that should help unblock folks.

Same issue for me on 5.10.0 - It’s working correctly until I switch on remote debugging.

Running into this issue with redux-persist@latest on Android only (tested on API 27 and API 23). Seems to work fine on iOS.

Happens regardless of whether the debugger is attached or not, and I tried using both AsyncStorage and FilesystemStorage.

Rolling back to 5.6.12 and 5.7.2 have both yielded positive results for me, and seem to work just fine.

For me issue appeared after upgrading RN to 0.60.0 and react-native-navigation to v4 and was resolved after I replaced previously recommended by wix android run script

"android": "cd ./android && ./gradlew app:assembleDebug && ./gradlew installDebug",

with the standard script

"android": "react-native run-android",

Same here: store config:

import { applyMiddleware, createStore, compose } from 'redux';
import { offline } from '@redux-offline/redux-offline';
import offlineConfig from '@redux-offline/redux-offline/lib/defaults';
import thunk from 'redux-thunk';
import { persistStore, persistReducer } from 'redux-persist'
import storage from 'redux-persist/lib/storage'

import rootReducer from './Reducers';


const persistConfig = {
  key: 'root',
  storage,
};

const persistedReducer = persistReducer(persistConfig, rootReducer)

const store = createStore(
  persistedReducer,
  {},
  compose(
    applyMiddleware(thunk),
    offline(offlineConfig)
  )
);

const persistor = persistStore(store);

export { persistor, store };

The problem happens the first time we open the app, if we gave a Reload it works and the error does not come back anymore. But I do not like the first time the user downloads the app it does not run at first.

"@redux-offline/redux-offline": "2.4.0",
"react-redux": "^6.0.1",  
"redux": "^4.0.1",
"redux-persist": "^5.10.0",

I tried with version 5.6.12 but the error persisted.

This may sound stupid but after uninstall, reinstalling, resetting metro, deleting artifacts (typescript), it still doesnt work on Android emulator.

Solution was to wipe the emulator data and start all over again. Emulator is butter smooth after wiping data as well. I think its a timeout/sync issue; the emulator bogs down after running for awhile.

@andrewzey Cool, I do like your approach handling real errors. Thanks for the Error Boundary suggestion.

What about the case where your app hits the timeout but without any exception being thrown. Cases like network connectivity problems, the user goes into a tunnel, turns on airplane mode, or something like that, and your app never throws an exception. Would Error Boundaries be able to solve that?

@ssorallen I tend to agree with you for the vast majority of cases, but there are some cases where having a “Reset state” button would be fine. I often build little test sandboxes where I rely on error boundaries that have “reset” buttons in them. I agree that for most customer-facing scenarios, it doesn’t make sense. TBD on whether my suggested “Reset” button will even make it in our app or not.

But the Error Boundary Solution does seem to work well, and it even presents an opportunity to show a feedback form where a user can describe what they were doing when the crash was encountered. That can really help debugging. To be fair though, that’s true of Error Boundaries in general, and has nothing to do with redux-persist.

What it shouldn’t do is then rehydrate your store with initialState, which is the current functionality.

I couldn’t agree more.

@andrewzey Using an error boundary makes sense, but I can’t understand a case where you would actually want catastrophic data loss (i.e. replacing the state with initial state after a timeout is reached). With the worst case you mentioned, “users will be stuck in a state where the app can’t ever start again”, you can push an update to your app to fix the hydration exception and those users can update the app to get going again without losing any data.

Having the same problem on 5.10.0 with react-native and AsyncStorage . Weird that it persists though all these versions.

As @ChristienGuy said, anyone meet this problem only in remote debugging, should check this comment https://github.com/facebook/react-native/issues/4470#issuecomment-302869193 , try to set the device time is exactly the same as your computer, or set the timeout more lager like 20 min (caution: set the timeout lager like this may have side effects, only use it when you know what it is )

using Redux Persist version 5.9.1 … same issue

After trying a few different versions to no avail, I restarted my computer like I would have on Windows98. Everything is back to normal and working again. It’s not a good solution, but may be worth a try if you are still stuck…(I was only getting the error in debug mode)

same here @ChristienGuy error when remote debugging :3