[CDRIVER-2777] mongoc_collection_watch prefers collection readConcern to the one in "opts" Created: 28/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   

Probably since change streams were implemented in 1.9.0 (CDRIVER-2233), they prefer the collection readConcern over the readConcern passed in "opts".

Details: _mongoc_change_stream_new_from_collection sets stream->read_concern to the collection's read concern, and copies the user-supplied options to stream->opts. Then in _make_cursor, we copy stream->opts to a local variable "command_opts", resulting in something like:

{"readConcern": {"level": "user supplied level"}, "serverId": 1, "sessionId": 1809617486}

We then append stream->read_concern to command_opts:

{"readConcern": {"level": "user supplied level"}, "serverId": 1, "sessionId": 1809617486, "readConcern": {"level": "from collection"}}

Now command_opts has two readConcern fields. A few layers deeper we call _mongoc_read_write_opts_parse, which is generated from IDL (CDRIVER-2373). For speed and simplicity, I deliberately implemented last-field-wins for duplicate fields in the IDL parsers instead of adding any logic to detect duplicates. In this case the readConcern from the collection is last, and that is the readConcern used.



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

Author:

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

Message: CDRIVER-2777 watch 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/d90d57c34d686f943485623b2920a00c74138891

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