If we are recovering, the lastApplied timestamp could be ahead of the common point in the case of rollback recovery because we do not update the lastAppliedOpTime until after we are done recovering the oplog. TransactionHistoryIterator by default does timestamped reads on the oplog using lastApplied. So this could race with the config.transactions table update (run by a different replication writer thread) whose commitTimestamp is less than the common point and thus less than the read timestamp of the TransactionHistoryIterator. WiredTiger enforces that the commit timestamp of non-prepared transactions (which is the case for config.transactions update) is newer than the latest active reader. See WT-4780. So, we need to make TransactionHistoryIterator read untimestamped to avoid violating WiredTiger rules. This is safe because there should be no concurrent write to the oplog and all oplog entries we need on the transaction oplog chain should also be visible under untimestamped reads.