We are under the constraint that we can't take locks, and accordingly can't do writes, during the catalog cache refresh.

This ticket is to figure out a way to either temporarily capture the config.collections data, or signal that we need to re-do a find later, then finally take action at this location in the shard version recovery process.

There are multiple ways this can be designed – whoever does this ticket can create something more generic, a way to signal actions that should be taken after a refresh, or it can be in-line logic that leads to a resharding util helper function that can process the state information.

No matter how this is designed, we must assert that the state and metadata changes are locally written before we exit the linked location. That is, on exit of recoverRefreshShardVersion, we should have always written any necessary state changes to config.localReshardingOperations.

We may have to make any async tasks happen in an onCommit handler. From Max in Slack:

the async task might need to be started in an onCommit() handler on the recovery unit then because it is possible for the storage transaction to abort (WUOW rollback not replication rollback)