After the resharding coordinator has transitioned into the "preparing-to-donate" state, it is required to establish the DonorStateMachines and RecipientStateMachines on the participant shards before proceeding with the remainder of the resharding operation. This synchronization every participant shard is aware of the resharding operation and will react accordingly to a subsequent _flushReshardingStateChange, _shardsvrCommitReshardCollection, or _shardsvrAbortReshardCollection command. The logic prior to _tellAllParticipantsReshardingStarted() is flawed because it possible for the resharding coordinator to
- Atomically write the config.collections and config.chunks entries for the temporary resharding collection, advance the state in the config.collections entry to be "preparing-to-donate" for the collection being resharded, and advance the state in config.reshardingOperations to be "preparing-to-donate".
- Receive an abortReshardCollection command either explicitly from the user or implicitly via a setFeatureCompatibilityVersion command.
- Skip waiting for the replica set transaction in step (1) to become majority-committed.
- Broadcast the _flushRoutingTableCacheUpdatesWithWriteConcern command to all participant shards using a $configTime prior to the replica set transaction from step (1) because the Timestamp from step (1) hasn't become majority-committed yet.
Shards receive the _flushRoutingTableCacheUpdatesWithWriteConcern command and observe a state of config.collections for the source collection and temporary resharding collection entries prior to the replica set transaction from step (1). In particular, the recipient shards would not observe the config.collections entry for the temporary resharding collection at all and would treat the namespace as unsharded. The shards therefore skip constructing the DonorStateMachine and RecipientStateMachine objects but responded ok:1 to the resharding coordinator as if they had.
The resharding coordinator continues to wait for the participant shards to update their state within the config.reshardingOperations document to "done" and signal they've finished their cleanup for the resharding operation. However, because the participants shards never constructed the DonorStateMachine and RecipientStateMachine object, they'll also never perform that update on the config.reshardingOperations document. This leads the resharding coordinator to wait indefinitely on this future.
Manual intervention on the config.reshardingOperations document would be required to unblock the resharding coordinator. The source collection will be unable to perform other sharding DDL commands in the meantime.