Currently, the aggregation command run by the ReshardingOplogFetcher against the each donor shard specifies readPreference "nearest" to avoid overloading the donor's primary. The read also specifies maxStalenessSeconds to 90 to avoid reading from a secondary that is "too stale". The issue with this setup is that if during the critical section , the aggregate command ends up targeting a secondary with staleness greater than the critical section timeout window, then it would not be able to reach the "final" oplog entry and enter the "strict-consistency" in time.