For a ClusterClientCursor on mongoS, we store the readPreference and readConcern on the cursor and restore them for getMores:

https://github.com/mongodb/mongo/blob/e5c7116913d04d66eb1c9d5cc15250167c37e2c3/src/mongo/s/query/cluster_client_cursor_params.h#L73-L74 https://github.com/mongodb/mongo/blob/e5c7116913d04d66eb1c9d5cc15250167c37e2c3/src/mongo/s/query/cluster_find.cpp#L449-L451

At present, for a ClientCursor on mongoD, we only store and restore the readConcern on the cursor, but not the readPreference:

https://github.com/mongodb/mongo/blob/e5c7116913d04d66eb1c9d5cc15250167c37e2c3/src/mongo/db/commands/getmore_cmd.cpp#L226

We noticed this limitation when implementing SERVER-55309 . We were able to work around this limitation in short term by changing AsyncResultsMerger::_askForNextBatch() to manually add the readPreference to the 'getmore' command before it sends the getmore command to the remote machine, but this was not the ideal fix to the underlying issue:

https://github.com/mongodb/mongo/blob/50315039df4c36d9cde809eaaf56c439ee767340/src/mongo/s/query/async_results_merger.cpp#L452

The goal of this task is to update ClientCursors on mongoD to store and restore the readPreference on a cursor, and to back out the work-around in AsyncResultsMerger::_askForNextBatch() that SERVER-55309 introduced.

For reference, here is the Jira ticket where the ClientCursor on mongoD was updated to store and restore the readConcern: https://jira.mongodb.org/browse/SERVER-31665