As a reminder, the moveRange/moveChunk command-flow is _clusterMoveChunk -> _configsvrMoveRange -> _shardsvrMoveRange, where _shardsvrMoveRange instantiates a MoveRangeCoordinator.

Before issuing _shardsvrMoveRange to the donor shard, the config server forces a routing table refresh, so its view is almost always up to date. In the rare cases where it is not, _shardsvrMoveRange may return an error other than StaleConfig when the shard no longer owns the migrated range.

Because the config server runs this through a router-role retry loop, a StaleConfig error would be retried transparently. However, if a different error is returned, it can propagate all the way back to the user.

The following event sequence is one example of how an incorrect error can bubble up to the user:

1. A moveChunk command is issued. Its command flow is: _clusterMoveChunk → _configsvrMoveRange → _shardsvrMoveRange.
2. The config server steps down. Because this produces a retryable error, mongos retries the operation. The donor shard is not aware of the retry and continues executing its existing MoveRangeCoordinator.
3. _configsvrMoveRange is retried before the migration commits. As a result, it uses the pre-commit routing table and issues a new _shardsvrMoveRange targeting the same shard that is already running the migration.
4. By the time the retried _shardsvrMoveRange runs, the chunk migration has already committed. However, instead of failing with StaleConfig, it fails with ResumableRangeDeleterDisabled because range deletion is already in progress on the donor shard, and this is being checked before whether the current shard owns the given range.

This regression was introduced in SERVER-127230 as part of the Authoritative Shards program. Before that change, the config server handled errors returned by _shardsvrMoveRange and checked whether the migration had already completed; if it had, the command returned OK to the user; right now this check is being skipped.