When we recover a prepared transaction, we re-apply the oplog entry and replay the operations in the transaction to get back to the prepare state. This line prevents us from adding a NumRecordsChange on the new recovery unit.

During rollback, say we commit a prepared transaction on the rollback node. This entry will get rolled back, the transaction will get invalidated (which releases our txnResources, including the recovery unit), and we will replay oplog entries from the stable timestamp. This involves putting the corresponding prepared transaction back into prepare.

Since the new recovery unit does not register the operations of the prepared transaction, when we decide to either commit/abort it, there is nothing to add or subtract to numRecords.

Previously, we have accounted for counts during rollback in _findRecordStoreCounts, where we calculate the diffs for each UUID. For prepared transactions, however, we are not sure if we will eventually commit or eventually abort the transaction. So, it might not make sense to preemptively change the counts.

Ideally, we would figure out a way for the new recovery unit to make an exception for prepared transactions that were recovered during rollback and make sure the changes get recorded when reapplying operations.