First, let's start a two shard cluster where each shard is a two-node replica set:

var st = new ShardingTest({shards: 2, rs: {nodes: 2}, mongos: 1});

This should result in shardsvr primaries running on ports 20000 and 20002, shardsvr secondaries running on 20001 and 20003, and a mongos running on 20007. Connecting to the mongos "admin" database, we have three ways of running a currentOp:

1. Directly run the currentOp command, using db.runCommand({currentOp: 1}).
2. Use a $currentOp pipeline, db.aggregate([\{$currentOp: {}}]).
3. Use the shell helper, db.currentOp().

Problem #1: While methods (1) and (2) will target the primaries on 20000 and 20002 as expected, the shell helper method (3) will target the secondaries on 20001 and 20003. I can see from the logs that the shell is sending readPreference mode "secondaryPreferred" to the server, which is not correct.

Problem #2: If I use the shell to set a "primaryPreferred" readPreference on the session, now both methods (2) and (3) erroneously target the secondary nodes. For example,

MongoDB Enterprise mongos> db.getSession().getOptions().setReadPreference("primaryPreferred")
MongoDB Enterprise mongos> db.aggregate([{$currentOp: {}}, {$group: {_id: "$host", count: {$sum: 1}}}]).pretty()
{ "_id" : "storchbox:20001", "count" : 16 }
{ "_id" : "storchbox:20003", "count" : 16 }

I can see from the logs that this operation sends a readPreference of "secondaryPreferred" to mongos, even though the readPreference configured in the shell is "primaryPreferred".

Problem #3: We should clarify what is supposed to happen when causal consistency is enabled via db.getMongo().setCausalConsistency(). At the moment, methods (1) and (2) will continue to target the primary nodes, but (3) will target the secondaries. This seems likely related to the other observations above, but I wanted to mention it explicitly so test authors know how to handle passthrough suites relying on causal consistency when the test uses currentOp.