[SERVER-31665] Obey read preference and utilize readConcern during lookup of an update post image during change stream Created: 20/Oct/17  Updated: 30/Oct/23  Resolved: 17/Nov/17

Status: Closed
Project: Core Server
Component/s: Aggregation Framework
Affects Version/s: None
Fix Version/s: 3.6.0-rc5, 3.7.1

Type: Bug Priority: Major - P3
Reporter: Charlie Swanson Assignee: Charlie Swanson
Resolution: Fixed Votes: 0
Labels: bkp
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Backports
Backwards Compatibility: Fully Compatible
Operating System: ALL
Backport Requested:
v3.6
Sprint: Repl 2017-11-13, Repl 2017-12-04
Participants:

 Description   

When using a change stream with fullDocument='updateLookup' against a sharded collection, the lookup will happen from mongos to the shards. This lookup should obey the read preference of the original command.

We should also use readConcern majority for this update, and use afterClusterTime to ensure we don't target to a secondary which is lagged behind the node that generated the change event.



 Comments   
Comment by Githook User [ 17/Nov/17 ]

Author:

{'name': 'Charlie Swanson', 'username': 'cswanson310', 'email': 'charlie.swanson@mongodb.com'}

Message: SERVER-31665 Use correct read concern/preference during update lookup

(cherry picked from commit f7122973bd8001bb8dd393b7ad7851493b8b7743)
Branch: v3.6
https://github.com/mongodb/mongo/commit/a0821b653d4beb879261b9232c66b95383dc86c6

Comment by Githook User [ 17/Nov/17 ]

Author:

{'name': 'Charlie Swanson', 'username': 'cswanson310', 'email': 'charlie.swanson@mongodb.com'}

Message: SERVER-31665 Use correct read concern/preference during update lookup
Branch: master
https://github.com/mongodb/mongo/commit/f7122973bd8001bb8dd393b7ad7851493b8b7743

Comment by Charlie Swanson [ 16/Nov/17 ]

Brief status update: the code review has been LGTM'd, the rebase onto master wasn't straightforward, and now I have a failing patch build: https://evergreen.mongodb.com/version/5a0c9ecde3c3315e3b013886

Investigating that now.

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