The _flushReshardingStateChange command uses the arbitraryExecutor in order to flush the metadata by calling onCollectionVersionPlacementMismatch.

This method may block by either:

• Taking a collection lock
• Waiting on the critical section future

This is a problem because the arbitrary executor does not expect any blocking methods to be called in there. This is because it is essentially always the same one in sharding, which is one that piggybacks on the Networking ASIO threads. This means that it will be a thread pool with a fixed size and prone to deadlocks if mishandled.

In this situation there is a potential deadlock waiting to happen given this scenario:

• Operation A is in a multi-document transaction against collection C which uses an AsyncResultsMerger.
• Operation B starts a resharding operation on C and enqueues a MODE_S lock since it cannot acquire it.
• Operation B triggers an eventual execution (Operation C) of the _flushReshardingStateChange command that blocks until the critical section is signalled by resharding.
• Operation A now attempts to kill the AsyncResultsMerger, this waits until all callbacks are executed to avoid invalid memory accesses. These callbacks are executed on the arbitraryExecutor.

At this point Operation A is waiting until Operation C finishes which waits on Operation B and in turn waits on Operation A again.