If a shardCollection request is executed while there is an ongoing create collection coordinator to either create or register an unsplittable collection, we will return ConflictingOperationInProgress error to the user.
Even if semantically these are two different operations, we use the same coordinator type to serve them. This means that the two coordinator will have the same coordinator ID and thus will conflict.
As depicted in the following table, in SERVER-81190 we already made so that when the incoming operation is to create/register an unsplittable collection we will serialize rather than throwing ConflictingOperationInProgress.
In this ticket, we will extend this approach in order to make sure that when the incoming operation is a shard collection, it will correctly serialize with other ongoing unsplittable operations (Yellow raws in the table):
Running op | Incoming op | Current Bheavior | Desired Bheaviour |
Implict Creation | Shard Collection | Error on conflict | Serialize |
Implicit Creation | Explicit creation | Serialize | Serialize |
Implict Creation | Implicit Creation | Serialize | Serialize |
Explicit creation | Shard Collection | Error on conflict | Serialize |
Explicit creation | Explicit creation | Serialize | Serialize |
Explicit creation | Implicit Creation | Serialize | Serialize |
Shard Collection | Shard Collection | Error on conflict | Error on conflict |
Shard Collection | Explicit creation | serialize | Serialize |
Shard Collection | Implicit Creation | serialize | Serialize |
- is depended on by
-
SERVER-89395 Balancer always fail to move untracked unsplittable collections
- Closed