Right now, every class that inherits from ChunkOperationShardingCoordinator runs the _checkSetAllowChunkOperations check during ShardingCoordinator initialization (here). This affects moveRange, mergeChunks, splitChunk, and mergeAllChunks, since their coordinators inherit from ChunkOperationShardingCoordinator, whose precondition hook calls _checkSetAllowChunkOperations().

This introduces two orthogonal issues.

• First, it changes the behavior of moveRange. If _checkSetAllowChunkOperations() throws StaleConfig because the metadata is not available, the resulting refresh can trigger migration recovery through an unexpected path. This is causing Evergreen failures, such as migration_coordinator_abort_failover.js. 

• Second, it makes these operations non-idempotent. The allowMigrations / allowChunkOperations checks run before we determine whether the operation was already completed by a previous attempt. As a result, a retry can fail even if the previous attempt already succeeded. This is especially problematic because allowMigrations and allowChunkOperations can be updated concurrently with ChunkOperationShardingCoordinator initialization.