SERVER-56321 aggregation without atClusterTime can read at a newer committed snapshot in shell_cursor_read_timestamp.js

1 files changed, 4 insertions, 2 deletions

diff --git a/jstests/noPassthrough/shell_cursor_read_timestamp.js b/jstests/noPassthrough/shell_cursor_read_timestamp.js
index f613ebba739..64c5b535489 100644
--- a/jstests/noPassthrough/shell_cursor_read_timestamp.js
+++ b/jstests/noPassthrough/shell_cursor_read_timestamp.js
@@ -54,9 +54,11 @@ cursor = collection.aggregate([{$sort: {_id: 1}}],
                               {readConcern: {level: "snapshot", atClusterTime: insertTimestamp}});
 assert.eq(cursor.getClusterTime(), insertTimestamp);
 
-// Test aggregate with snapshot readConcern.
+// Test aggregate with snapshot readConcern. Similarly to the find with snapshot readConcern and no
+// 'atClusterTime', it's possible that this aggregate can read at a newer snapshot than
+// 'insertTimestamp'.
 cursor = collection.aggregate([{$sort: {_id: 1}}], {readConcern: {level: "snapshot"}});
-assert.eq(cursor.getClusterTime(), insertTimestamp);
+assert.gte(cursor.getClusterTime(), insertTimestamp);
 
 // Test aggregate with non-snapshot readConcern.
 cursor = collection.aggregate([{$sort: {_id: 1}}]);