Problematic behavior

During a chunk migration, the recipient checks if it's receiving its first chunk; if it is, it triggers additional code to clean up leftovers from previous instances of the collection. This is implemented by isFirstMigration.

This is done based on CSR state. However we handle an UNKNOWN CSR (i.e. we don't know anything about the collection), by returning "Not first migration" (in v8.3 and lower) or "First migration" (in v9.0).

In general this conclusion could be incorrect, and we should instead trigger a CSR refresh if it the CSR is UNKNOWN so that we can make the decision based on fresh/correct metadata.

It should be noted that the recipient triggers a refresh shortly before this path so in practice the CSR is almost never UNKNOWN. However a concurrent DDL can clear the CSR after that refresh (see attached patch).

Impact

The associated "first migration" cleanup behavior is dropping any indexes that the recipient has but the donor doesn't, mainly intended to handle this case:

• Shard0 and Shard1 own chunks for "coll".
• User creates a {x:1} for "coll".
• User moves all chunks of "coll" to Shard0.
• User drops the index {x:1} for "coll" –> Only targets Shard0, so a leftover {x:1} index remains on Shard1.
• User moves a chunk of "coll" to Shard1 again --> This should trigger the cleanup which drops the {x:1} index on Shard1.

This can lead to the following user visible impact:

• If we return "Not first migration" but it's actually the first migration --> We won't drop leftover indexes on the shard, this could later cause migrations to fail (e.g. due to unique index conflicts).
• If we return "First migration" but it's actually not the first migration --> We will drop any extra indexes on the recipient, e.g. indexes the user has directly created on the shard, or indexes which could only successfully complete on a subset of shards.