To deal with this, I'm copying this project's createMigrate.js and modifying it in my project to this: https://gist.github.com/aguynamedben/ee5ef358856f1543129265fd3cf8b732

See the tests for how to use it...

      const asyncMigrations = {
        1: async (state) => {
          return {
            ...state,
            foo: 'different',
          };
        },
        2: async (state) => {
          return {
            ...state,
            baz: 'bang',
          };
        },
        3: async (state) => {
          return {
            ...state,
            cool: 'beans',
          };
        },
      };

configureStore.dev.js

  const persistConfig = {
    key: 'root',
    storage: storage,
    debug: true,

    migrate: customCreateMigrate(asyncMigrations, {
      debug: true,
      asyncMigrations: true,
    }),
    version: 8,
  };

We use the same logic in customCreate.js to figure out which migrations to run. For async migrations, we use this technique to dynamically build a promise chain using Array.reduce(). This means the async migrations are run in sequence, one after another.

With the current code, you must provide the option { asyncMigrations: true } or else the old logic is used, which will screw up if you have async migrations.

If #929 gets resolved I'd happily submit a PR to add this. I think we could even detect if the migration function is async and resolve automatically so that specifying the asyncMigrations option isn't necessary.

I need to submit my gist as a PR.

I'm not sure if this is also related to feature requests for async transforms. #303 I need to figure that out. It seems like they might be separate per this comment: #426 (comment)

Also maybe related: #426

Fixed in #1219