Calls to the config shard right now are done via the help of ShardRegistry::getConfigShard() which returns a ConfigShardWrapper instance. This wrapper is in charge of attaching the configTime to the requests sent to the config server.

However, the approach chosen is flaky since the causal consistency expected here is not enforced and instead offered as a best-effort. This is because the code uses the minClusterTime setting in the ReadConcernPreferences. This is exclusively used for choosing which node to route the request to but is ignored if no node satisfies it (code that does this).

This means that theoretically if the wrong node is chosen it could be reading stale data if they do not set a valid readConcern clusterTime.

This is currently the case if the node chosen is a stale secondary accessing itself via the RSLocalClient as part of ShardLocal.