Loading...
Loading...
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()}});
MongoDB Integration
Learn more about where this data comes from
Bug Scrub Advisor
Streamline upgrades with automated vendor bug scrubs
BugZero Enterprise
Wish you caught this bug sooner? Get proactive today.