While applying the delete related oplog entries in resharding, there is a case when twice the number of locks are requested. The new client created within runWithTransaction() acquires its own lock over the collections and thereby requesting its own ticket which leads to contention with the tickets held by the outer client. The ticket pool size is no longer fixed at 128, but adjustable based on the throughput rates, and thereby in some scenarios there are not enough tickets to distribute amongst the threads causing some of them to be stuck in a retry loop.

Possible solutions are: to not have  runWithTransaction() acquire its own locks over the collection or to not allow the outer client to acquire locks when delete oplog entries are being applied.