SERVER-35763 lastWriteDate field can get out of sync between repl set nodes during migration

Revert changes to onMigrateCompletedOnPrimary to make it easier for secondary to replicate config.transactions idempotently.

(cherry picked from commit 57d007e00124d18e94c204e3968b53f83c01f1b7)

1 files changed, 2 insertions, 9 deletions

diff --git a/src/mongo/db/session.cpp b/src/mongo/db/session.cpp
index a3fd6c3cef2..d45849a207c 100644
--- a/src/mongo/db/session.cpp
+++ b/src/mongo/db/session.cpp
@@ -470,16 +470,9 @@ void Session::onMigrateCompletedOnPrimary(OperationContext* opCtx,
     _checkValid(ul);
     _checkIsActiveTransaction(ul, txnNumber, false);
 
-    // If the transaction has a populated lastWriteDate, we will use that as the most up-to-date
-    // value. Using the lastWriteDate from the oplog being migrated may move the lastWriteDate
-    // back. However, in the case that the transaction doesn't have the lastWriteDate populated,
-    // the oplog's value serves as a best-case fallback.
-    const auto txnLastStmtIdWriteDate = _getLastWriteDate(ul, txnNumber);
-    const auto updatedLastStmtIdWriteDate =
-        txnLastStmtIdWriteDate == Date_t::min() ? oplogLastStmtIdWriteDate : txnLastStmtIdWriteDate;
-
+    // We do not migrate transaction oplog entries.
     const auto updateRequest =
-        _makeUpdateRequest(ul, txnNumber, lastStmtIdWriteOpTime, updatedLastStmtIdWriteDate);
+        _makeUpdateRequest(ul, txnNumber, lastStmtIdWriteOpTime, oplogLastStmtIdWriteDate);
 
     ul.unlock();