Uploaded image for project: 'Core Server'
  1. Core Server
  2. SERVER-29434

Don't accept empty timestamps for readConcern afterClusterTime

    XMLWordPrintableJSON

Details

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Major - P3 Major - P3
    • 3.5.9
    • 3.5.8
    • Sharding
    • None
    • Fully Compatible
    • ALL
    • Hide

      ./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()}});
      

      Show
      ./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()}});
    • Sharding 2017-06-19
    • 0

    Description

      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.

      Attachments

        Activity

          People

            jack.mulrow@mongodb.com Jack Mulrow
            jack.mulrow@mongodb.com Jack Mulrow
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: