[SERVER-34496] Await all operations committed in ShardingTest::checkUUIDsConsistent hook (lookup.js) Created: 16/Apr/18  Updated: 29/Oct/23  Resolved: 20/Apr/18

Status: Closed
Project: Core Server
Component/s: Sharding
Affects Version/s: None
Fix Version/s: 3.7.6

Type: Bug Priority: Major - P3
Reporter: Jack Mulrow Assignee: Blake Oler
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Backwards Compatibility: Fully Compatible
Operating System: ALL
Sprint: Sharding 2018-04-23
Participants:
Linked BF Score: 56

 Description   

jstests/aggregation/sources/lookup/lookup.js manually creates a ShardingTest, and because it can run in a read concern majority passthrough, the checkUUIDs hook can be overriden to run with majority read concern, which it does not support because the metadata collections it reads from are written with local write concern. SERVER-33876 made ShardingTest default to 1 node replica sets instead of standalone nodes, which exposes this problem because now locally written data is not guaranteed to be immediately seen by majority reads.

The checkUUIDs hook should await all operations to be committed before checking the shard metadata collections.



 Comments   
Comment by Githook User [ 20/Apr/18 ]

Author:

{'email': 'blake.oler@mongodb.com', 'username': 'BlakeIsBlake', 'name': 'Blake Oler'}

Message: SERVER-34496 Await all operations committed in ShardingTest::checkUUIDsConsistent hook
Branch: master
https://github.com/mongodb/mongo/commit/ebfdd0f68c1c9477cf5795bd07256d596fea62c5

Comment by Max Hirschhorn [ 20/Apr/18 ]

Would we want to instead change the set_read_and_write_concerns.js override method to not inject a read concern or write concern when the connection is to a mongos process and the operation is against the "admin" or "config" databases? We had changed the set_read_preference_secondary.js override method to behave this way in fe88a74 as part of SERVER-32920.

Edit: Nevermind, I like the idea of having the data consistency check wait for replication in order to ensure the data is visible at any read concern.

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