Sharded DDL commands generally create a ShardingDDLCoordinator, then block until completion by waiting on its completion future. After the command gets unblocked, it can return the result back to the user which may run follow-up commands with the expectation that the operation is fully complete.

However, the de-activation of the ShardingDDLCoordinator from the ShardingDDLCoordinatorService concurrently waits on this same future, and there is no guarantee that it gets scheduled on a timely manner. This can for example cause setFCV to find a conflicting addShard coordinator still active, even if addShard and setFCV are run sequentially.