...
BugZero found this defect 2784 days ago.
Right now, a user can trigger this invariant in _waitUntilClusterTimeForRead by submitting a request with: readConcern: {level: "majority", afterClusterTime: Timestamp()} or readConcern: {level: "majority", afterClusterTime: Timestamp(0, 0)} I think the easiest way to fix this would be returning ErrorCodes::InvalidOptions in read_concern_args.cpp::initialize if _clusterTime == LogicalTime::kUninitialized. We could also remove the invariant, or change it to a uassert.
xgen-internal-githook commented on Wed, 7 Jun 2017 14:26:11 +0000: Author: {u'username': u'jsmulrow', u'name': u'Jack Mulrow', u'email': u'jack.mulrow@mongodb.com'} Message: SERVER-29434 Don't accept empty timestamps for readConcern afterClusterTime Branch: master https://github.com/mongodb/mongo/commit/00dd041c28f0f88cb2478b3be22c50f97515b437 xgen-internal-githook commented on Tue, 6 Jun 2017 17:11:18 +0000: Author: {u'username': u'judahschvimer', u'name': u'Judah Schvimer', u'email': u'judah@mongodb.com'} Message: Revert "SERVER-29434 Don't accept empty timestamps for readConcern afterClusterTime" This reverts commit 783d11c4ea92784dc6ca0cc0419403c454c9ec9c. Branch: master https://github.com/mongodb/mongo/commit/39cd3e84fc60f67112f2c1182207dcf9b13be967 xgen-internal-githook commented on Tue, 6 Jun 2017 14:57:16 +0000: Author: {u'username': u'jsmulrow', u'name': u'Jack Mulrow', u'email': u'jack.mulrow@mongodb.com'} Message: SERVER-29434 Don't accept empty timestamps for readConcern afterClusterTime Branch: master https://github.com/mongodb/mongo/commit/783d11c4ea92784dc6ca0cc0419403c454c9ec9c
./mongo --nodb let st = new ShardingTest({rs: {enableMajorityReadConcern: ""}}); st.s.getDB("test").insert({x: 1}); st.s.getDB("test").runCommand({find: "foo", readConcern: {level: "majority", afterClusterTime: Timestamp()}});