In snapshot_read_utils.js, there is a procedure to abort any transaction started by the FSM workload. It runs abortTransaction on all txnNumbers from the latest one the thread could have used down to 0:

for (let i = data.txnNumber; i >= 0; i--) {
    let res = abortTransaction(data.sessionDb, i, abortErrorCodes);
    if (res.ok === 1) {
        break;
    }
}

Unfortunately, this procedure no longer works. If there is an open transaction with txnNumber=i, then when we run abortTransaction with txnNumber=j>i, we receive an error NoSuchTransaction with message "Given transaction number j does not match any in-progress transactions. The active transaction number is i". Then when we try to run abortTransaction with txnNumber=i, we receive an error TransactionTooOld with message "Cannot start transaction i on session <lsid> because a newer transaction j has already started". The transaction with txnNumber=i then remains open after the cleanup procedure is done.

This can be fixed by running abortTransaction on each txnNumber in increasing order.

This issue does not exist on 4.0, since on 4.0, we error if we receive a higher txnNumber without startTransaction:true prior to bumping the txnNumber on Session. This issue is new with the Session refactor.