[CDRIVER-2775] mongoc_collection_find_with_opts prefers collection readConcern to the one in "opts" Created: 27/Jul/18  Updated: 28/Oct/23  Resolved: 30/Jul/18

Status: Closed
Project: C Driver
Component/s: libmongoc
Affects Version/s: None
Fix Version/s: 1.13.0

Type: Bug Priority: Major - P3
Reporter: A. Jesse Jiryu Davis Assignee: A. Jesse Jiryu Davis
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Epic Link: Test option inheritance

 Description   

If the user provides a readConcern in "opts" it should take precedence over the collection's readConcern. However, mongoc_collection_find_with_opts prefers the wrong readConcern.



 Comments   
Comment by Githook User [ 30/Jul/18 ]

Author:

{'username': 'ajdavis', 'name': 'A. Jesse Jiryu Davis', 'email': 'jesse@mongodb.com'}

Message: CDRIVER-2775 test readConcern inheritance in txn

Additional test that sets a collection-level readConcern and passes a
readConcern to mongoc_collection_find_with_opts; the operation should
still fail because explicit readConcern is prohibited in transaction.
Branch: master
https://github.com/mongodb/mongo-c-driver/commit/72063936b975fc2e5745455065196ccebee63271

Comment by Githook User [ 28/Jul/18 ]

Author:

{'username': 'ajdavis', 'name': 'A. Jesse Jiryu Davis', 'email': 'jesse@mongodb.com'}

Message: CDRIVER-2775 find prefers readConcern from opts

Don't use the collection's readConcern if there is a "readConcern" key
in "opts".
Branch: master
https://github.com/mongodb/mongo-c-driver/commit/2edd3b2a91171a5da88e9282ffb6a3efbbc2bd91

Comment by A. Jesse Jiryu Davis [ 27/Jul/18 ]

We introduced mongoc_collection_find_with_opts in 1.5.0 and said that readConcern would be prohibited in opts (CDRIVER-1522), although that wasn't enforced client-side. In fact, if readConcern is provided in opts then mongoc_collection_find_with_opts would use it, and if readConcern was also set on the collection then mongoc_collection_find_with_opts would send both, causing a server side "duplicate field" error. (Don't know for how long the server has been checking for duplicates.)

readConcern: {level: 'foo'}, readConcern: {level: 'bar'}

That changed in 1.10.0 when we released cursor code that was refactored in CDRIVER-2502. After that we passed both readConcern levels:

readConcern: {level: 'foo', level: 'bar'}

In 1.11.0 as part of readConcern updates for transactions, that changed again and we now pass a single readConcern level, but it's the wrong one: the collection's.

Before this is closed I must also test that if readConcern is set on the collection and passed in 'opts' and we're in a transaction, it's a client-side error.

Comment by Jeremy Mikola [ 27/Jul/18 ]

jesse: What's the affected version of this bug? I assume it dates back to whenever a readConcern option was first introduced to mongoc_collection_find_with_opts().

derick: FYI, this isn't a problem for PHPC as we apply the Query's read concern directly to the collection. It may be worth having a ticket to refactor that once we bump to libmongoc 1.13, though, as relying on mongoc_collection_find_with_opts() would allow us to handle the option consistently with other Query options.

Generated at Wed Feb 07 21:16:18 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.