The aggregation command run by the ReshardingCollectionCloner against the each donor shard specifies readPreference "nearest" to avoid overloading the donor's primary. Currently, the command doesn't specify maxStalenessSeconds. As a result, the aggregate command could end up targeting a node that is so stale and later end up transitioning to the RECOVERING state because the oplog entries it needs have truncated etc. If the transition occurs while the read is waiting for the readConcern's afterClusterTime, by design the operation will be not interrupted. So the resharding operation would get stuck trying to start the cloning phase until the node is shutdown.

According to the replication team, Atlas has the mechanism to detect that a node has transitioned to RECOVERING and perform intervention to turn the node back into a healthy state (e.g. via initial sync). So supposedly, this fix is only necessary for non-Atlas use cases.