When a new retryable transaction runs on a mongod and a retryable transaction for the same client retryable write (ie same txnNumber in the session id) is active, the incoming transaction must wait for the existing transaction to complete, which happens via throwing a RetryableTransactionInProgress exception. This is meant to avoid a livelock if multiple routers are running the same client retryable write that requires retryable transactions, e.g. after a network error between a client and a mongos that leads the client to retry on a different mongos. A downside of this is if the router for the existing transaction has crashed or otherwise given up (e.g. after certain Interruption errors) the incoming transaction from the retry will wait for the existing transaction to time out. In practice, it is likely the original router has stopped running the transaction if a retry arrives, so the retry should interrupt the existing transaction. But to prevent livelocks if the original router is still running, only the first conflict should cause an interruption.