The runCommand methods on the ShardRegistry type that currently take a HostAndPort argument should actually take a ReadPreferenceSetting and either a Shard or a Targeter. The problem with the current form is that the targeter is given a read preference by code trying to run commands against shards in order to derive a HostAndPort. The code trying to run commands is not then obligated (or sometimes even enabled) to appropriately set the $secondaryOk metadata field. Given the uses, a better design would be for the runCommand-like methods to take a Shard or Targeter along with a read preference, and to do targeting and command dispatch together.

Making this change will hopefully eliminate bugs where operations are targeted to secondary nodes without setting the $secondaryOk flag.