Read concern level snapshot executes speculatively if the command is run as part of a transaction and atClusterTime is not provided. However, we allow read concern level snapshot if the command is run as part of an active or killed transaction. This means that if the transaction has been killed, we will wait for read concern with non-speculative behavior. This behavior is not supported. When atClusterTime is not specified, we always expect transactions to execute speculatively. One issue that could arise is that on mongods with enableMajorityReadConcern:"false", we will attempt to obtain a majority committed snapshot. This always returns a non-ok status, so we will loop forever waiting for majority reads to become available.

Note that we expect this issue to be rare outside of tests. It only occurs when a readConcern is specified on the operation, which a driver would only do if it is the first operation of the transaction. For a transaction to be killed on the first operation in a transaction, before the waitForReadConcern, there would need to be a concurrent killSessions. This issue is more likely to occur if there is a readConcern on a subsequent transaction operation, which a driver would not do. In that case, the transaction could have been aborted earlier for any reason. We wait for read concern here before we unstash resources here, which throws if a read concern is provided and the transaction is in progress, so we do not catch the problem until we have already waited.