Currently, for any exception thrown after beginOrContinue and before unstashTransactionResources finishes, we don't abort the unprepared transactions implicitly. Instead we wait for it to abort eventually, either by the transaction reaper or any future requests with higher transaction number. To be noted, reaper would only abort the expired transactions and their life time of the transaction is controlled by an user defined server parameter transactionLifetimeLimitSeconds. As a result, we are holding the transaction lock and storage resources for an unbounded period of time that would make other DDL/CRUD operations to starve. So, it's good to reclaim the lock and storage resources early from the failed transaction.

Note: Any individual statements in a transaction other than commit/abort cmd are definitely not retryable even if we attach a retyable error code as we attach TransientTransaction Error (TTE) label to it. TTE signals that it's safe to retry the entire transaction.