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

Don't accept empty timestamps for readConcern afterClusterTime

XMLWordPrintableJSON

    • Type: Icon: Bug Bug
    • Resolution: Fixed
    • Priority: Icon: Major - P3 Major - P3
    • 3.5.9
    • Affects Version/s: 3.5.8
    • Component/s: 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

      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.

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

              Created:
              Updated:
              Resolved: