When users disable migrations for a collection via setAllowMigrations, they may expect these two main effects:

• To avoid data being migrated between shards.
• To avoid new range deletion tasks being created.

However, this is not what currently happens if a moveChunk/moveRange operation kicks in.

When migrations are disabled through setAllowMigrations, a moveChunk/moveRange operation does not observe that migrations are disabled until it reaches the commit phase (in particular, here), which occurs after documents have already been cloned to the recipient shard. Once the migration is then aborted because permitMigrations is false, the recipient shard still creates a range deletion task covering all cloned documents.

As a result, it is not safe to rely on setAllowMigrations to guarantee a steady state with no data migration and no new range deletions.