If a user starts a transaction with no readConcern level (the default), the transaction reads from the all-committed snapshot instead of at the last applied timestamp. The expected behavior is if there is no readConcern level it behaves the same as an explicit readConcern level "local" and reads from the last applied timestamp.

Transactions with an explicit readConcern level "local" behave correctly, the bug affects the default common case, with no explicit level.

Details: In _extractReadConcern in service_entry_point common, if we're starting a multi-statement transaction, we save the user's readConcern level as ReadConcernArgs::_originalLevel, and replace ReadConcernArgs::_level with kSnapshot. Later, we determine whether to read from a snapshot by calling ReadConcernArgs::getOriginalLevel(). judah.schvimer says the intention of this is to make readConcern::getLevel() return kSnapshot in all multi-statement transactions. He says "We upconvert all readconcerns to snapshot for ease of coding, but we use the original read concern level when calling _setSpeculativeTransactionOpTime". (I, Jesse, don't know how this eases coding yet.)

However, getOriginalLevel() doesn't fulfill this intention. If the client provides no readConcern, then ReadConcernArgs::_originalLevel is boost::none. Then getOriginalLevel() does:

    return _originalLevel.value_or(getLevel());

... which is the upconverted level, "snapshot"!