SERVER-33249 readConcern_atClusterTime_snapshot_selection.js should ensure the commit point moves forward

1 files changed, 13 insertions, 3 deletions

diff --git a/jstests/noPassthrough/readConcern_atClusterTime_snapshot_selection.js b/jstests/noPassthrough/readConcern_atClusterTime_snapshot_selection.js
index e99b3e27857..90aa1608a9d 100644
--- a/jstests/noPassthrough/readConcern_atClusterTime_snapshot_selection.js
+++ b/jstests/noPassthrough/readConcern_atClusterTime_snapshot_selection.js
@@ -41,10 +41,20 @@
     let clusterTimeBefore = res.opTime.ts;
 
     // Wait for the majority commit point to reach 'clusterTimeBefore' on the secondary.
-    assert.soon(function() {
+    assert.soonNoExcept(function() {
+        // Without a consistent stream of writes, secondary majority reads are not guaranteed
+        // to complete, since the commit point being stale is not sufficient to establish a sync
+        // source.
+        // TODO (SERVER-33248): Remove this write and increase the maxTimeMS on the read.
+        res = assert.commandWorked(primaryDB.runCommand(
+            {insert: "otherColl", documents: [{a: 1}], writeConcern: {w: "majority"}}));
+        assert(res.hasOwnProperty("opTime"), tojson(res));
+        assert(res.opTime.hasOwnProperty("ts"), tojson(res));
+        clusterTimeBefore = res.opTime.ts;
+
         return assert
-                   .commandWorked(
-                       secondaryDB0.runCommand({find: collName, readConcern: {level: "majority"}}))
+                   .commandWorked(secondaryDB0.runCommand(
+                       {find: collName, readConcern: {level: "majority"}, maxTimeMS: 10000}))
                    .cursor.firstBatch.length === 1;
     });