Consider a shard with two nodes: n0 (primary) and n1 (secondary). We run a findAndModify command with pre/post image in a retryable internal transaction on the shard, and then we run a prepareTransaction command. As part of preparing the transaction, n0 writes an applyOps oplog entry and a config.image_collection entry for the transaction. The writes are done in a separate RecoveryUnit (i.e. storage transaction) from the one for the transaction. As part of applying the applyOps oplog entry for the transaction, n1 also writes a config.image_collection entry for it. However, the write is done in the same RecoveryUnit as the one for the transaction. As a result, the config.image_collection IX lock does not get released when the write completes (i.e. it is held along with other locks acquired for the transaction until the transaction commits or aborts). While the transaction is in prepare, n0 steps down. There are two cases:

• If n1 steps up, the stepup hook would hang inside IndexBuildsCoordinator::onStepUp() because it cannot acquire the config database X lock while the config.image_collection IX lock is still being held by the prepared transaction.

• If n0 steps up, the stepup hook would not hang since the config.image_collection IX lock is not being held by the prepared transaction.