As part of waitForReadConcernImpl, we could perform noop writes to bump up the clusterTime for afterClusterTime/atClusterTime. And that eventually calls Shard::runCommand to run the appendOplogNote command. On config servers (I believe we use ShardLocal}, this then calls ShardLocal::_runCommand which will then run the appendOplogNote using DBDirectClient. And this could override the readConcernArgs on the opCtx. Overriding the readConcernArgs on the opCtx is dangerous because the subsequent waitUntilOpTimeForRead call relies on the readConcernArgs to wait properly before proceeding with the command. Moreover, this could also affect other assumptions we have with the readConcern for the initial command.