Currently:

1. Upon transitioning to the “cloning” state, the ReshardingOplogFetcher on each recipient starts running aggregate commands to fetch oplog entries with readPreference “nearest”
2. SERVER-103554 Upon transitioning to the “blocking-writes” state, the coordinator tells each recipient to refresh the shard version. Previously, it used to only do that for donors. The refresh causes each recipient to notify its ReshardingOplogFetcher to interrupt any in-progress aggregate/getMore command and start the new ones with readPreference “primary”.

From the latest testing results, that is not sufficient. 

• If a recipient has been fetching oplog entries from stale secondaries. The remaining time estimate might be very off. For example, when the estimate is performed, the numbers of oplog entries fetched and applied are both 3000 (so the estimated remaining time is 0). But the total number of entries to fetch is 5000. The recipient may not finish fetching and applying the remaining 2000 within the critical section timeout of 5 seconds.
• SERVER-104303 does not solve this problem because it only accounts for majority replication lag (since the writes to enter or exit the critical section use w: majority not w: all), and the recipient could be fetching from a secondary that is not part of the majority.

The proposal is as follows. During the “applying” state, if the remaining time estimate calculated as part of a _shardsvrReshardingOperationTime command is less than some threshold (configurable via sever parameter), the ReshardingOplogFetcher would start using readPreference “primary” for new aggregate commands. Similar to in SERVER-103554, any in-progress aggregation (aggregate/getMore command) would be interrupted.