Since MongoDB v8.0, it is possible for an unsharded collection to be placed in any shard via the moveCollection command or the unshardCollection command. Under the hood, both commands create an unsplittable collection which is technically similar to a sharded collection with a single chunk. However, an unsplittable collection can be sharded via shardCollection (unlike an already sharded collection, for which reshardCollection must be used).

When an unsplittable collection is created either via moveCollection or unshardCollection, all its data is moved to its recipient shard, however, the shards that used to own data for that collection, including the DB-primary shard, still maintain an instance of the collection on their local catalog, but this instance is not updated by operations such as createIndexes or dropIndexes, so its can become stale.

This is problematic because shardCollection checks that all unique indexes for the collection to be sharded are prefixes of the shard key (as otherwise, the uniqueness constraint can not be enforced). However, currently, shardCollection first adds any additional indexes back to the DB-primary and then it runs the check against the instance of the collection on the DB-primary. However, the index sync process does not drop any surplus indexes that only the DB-primary has. Therefore, it will still find the unique index that the DB-primary used to contain which was then dropped after the collection was moved off of the DB-primary. This will make the shardCollection operation fail spuriously, giving as the reason an index that has already been dropped from the user point of view (see "Steps to Reproduce").

shardCollection should drop any surplus indexes on the DB-primary shard (as part of the SyncIndexesOnCoordinator phase) to ensure stale indexes can not block sharding.

As a workaround the collection can be moved back to the DB-primary shard before sharding it.