Filed to investigate why, and if its expected update the docs to warn users that follow up reads will not be causally consistent with the findAndModify unless it uses w:majority.
the issue logs:
https://evergreen.mongodb.com/task/mongodb_mongo_master_enterprise_rhel_62_64_bit_causally_consistent_jscore_passthrough_auth_WT_c7aa40633696a49fea2e75750b30a8339117d072_17_06_16_16_23_00
After the root cause is determined here is the proposal to address the issue:
1. Add OperationContext argument to interface EgressMetadataHook::readReplyMetadata
virtual Status readReplyMetadata(OperationContext* opCtx, StringData replySource, const BSONObj& metadataObj) = 0;
2. In ShardingConnectionHook::onCreate add the opCtx for replyMetadataReader:
if (_shardedConnections) {
conn->setReplyMetadataReader([this](OperationContext* opCtx, const BSONObj& metadataObj, StringData target) {
return _egressHook->readReplyMetadata(opCtx, target, metadataObj);
});
}
3. in DBClientWithCommands::runCommandWithTarget pass the operationContext to the _metadataReader call
Reading OperationTime
4. add OperationTimeHook class
Status OperationTimeHook::readReplyMetadata(OperationContext* opCtx, StringData replySource,
const BSONObj& metadataObj) {
std::shared_ptr<OperationTimeTracker> timeTracker = OperationTimeTracker::get(opCtx);
auto operationTime =metadataObj[kOperationTimeField];
if (!operationTime.eoo()) {
invariant(operationTime.type() == BSONType::bsonTimestamp);
timeTracker->updateOperationTime(LogicalTime(operationTime.timestamp()));
}
}
5. install OperationTimeHook to the hook list in runMongosServer
unshardedHookList->addHook(stdx::make_unique<rpc::OperationTimeHook>()); shardedHookList->addHook(stdx::make_unique<rpc::OperationTimeHook>());
- is duplicated by
-
SERVER-29455 Mongos egress operations over DBClient must update OperationTimeTracker
-
- Closed
-
- is related to
-
SERVER-29629 Add causally consistent passthrough with auth
-
- Closed
-