[SERVER-31404] getMore commands should return an error when the caller specifies a read concern Created: 05/Oct/17  Updated: 06/Dec/22

Status: Backlog
Project: Core Server
Component/s: Replication
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Andy Schwerin Assignee: Backlog - Query Optimization
Resolution: Unresolved Votes: 0
Labels: gm-ack, query-44-grooming
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
related to SERVER-32102 Audit tests in change_streams_seconda... Closed
is related to DRIVERS-415 Ensure that readConcern is not sent a... Blocked
Assigned Teams:
Query Optimization
Operating System: ALL
Participants:
Linked BF Score: 0

 Description   

It is not generally meaningful for client drivers to attach a readConcern argument to getMore commands. The purpose of readConcern is to set the isolation and consistency behavior for a newly issued query, and the purpose of getMore is to fetch a batch of documents from a cursor established by a previously issued query. Furthermore, the getMore command is an implementation detail of the driver and servers, rather than an interface presented to client applications. As such, mongodb servers must either ignore readConcern on getMore commands or reject getMore commands with readConcern arguments as malformed when such commands come from external clients.

Returning an error is less subject to misinterpretation by driver authors, and so is the suggested approach.



 Comments   
Comment by Gregory McKeon (Inactive) [ 26/Jan/18 ]

Sending to Query for triage.

Comment by Charlie Swanson [ 05/Oct/17 ]

spencer see the conversation on the BF, there was an idea to allow it exclusively from mongos to mongod.

Comment by Spencer Brody (Inactive) [ 05/Oct/17 ]

schwerin, this change would preclude our current plan to use afterClusterTime readConcern to decrease change stream latency in the presence of an idle shard, by using the afterClusterTime machinery to generate no-op writes (SERVER-29258).

Generated at Thu Feb 08 04:26:57 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.