[SERVER-45651] ReplSetTest stopSet checks should pass explicit RWC Created: 18/Jan/20  Updated: 29/Oct/23  Resolved: 13/Feb/20

Status: Closed
Project: Core Server
Component/s: Replication, Testing Infrastructure
Affects Version/s: None
Fix Version/s: 4.3.4

Type: Bug Priority: Major - P3
Reporter: Vesselina Ratcheva (Inactive) Assignee: Kevin Pulo
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
depends on SERVER-45940 Read/write concern jstest command ove... Closed
Backwards Compatibility: Fully Compatible
Operating System: ALL
Sprint: Repl 2020-01-27, Sharding 2020-02-10, Sharding 2020-02-24
Participants:
Linked BF Score: 11

 Description   

The consistency checks performed inside ReplSetTest stopSet() do not pass explicit read/write concern (RWC), instead assuming that the implicit server defaults will be applied (which was true historically). However, this is not the case if the RWC defaults have been applied to the ReplSetTest inside the jstest, leading to failures and/or incorrect semantics (ie. potentially flawed checks). Therefore the server operations performed by these consistency checks should pass explicit RWC corresponding to the implicit server defaults of {w: 1} and {level: "local"}, where those operations permit RWC.


Original summary

checkReplicaSet should set an explicit writeConcern when running collMod

Original description:

As part of the repl consistency checks in replsettest.js, we run a collMod (to wait for any index builds that may be in progress). That command is run without a writeConcern set, so it will inherit the default WC, which may have been changed during the execution of a test. We should pass in a WC explicitly so it doesn't depend on that.



 Comments   
Comment by Githook User [ 13/Feb/20 ]

Author:

{'username': 'devkev', 'name': 'Kevin Pulo', 'email': 'kevin.pulo@mongodb.com'}

Message: SERVER-45651 ReplSetTest stopSet checks should pass explicit RWC
Branch: master
https://github.com/mongodb/mongo/commit/d2c18cfec00f3a43815dc524df3912cfb1e0198a

Comment by Githook User [ 04/Feb/20 ]

Author:

{'name': 'Janna Golden', 'username': 'jannaerin', 'email': 'janna.golden@mongodb.com'}

Message: Revert "SERVER-45651 Ensure checkReplicaSet sets an explicit writeConcern when running collMod"

This reverts commit 74c4bcd1d353434bb3b89fd7db3604090b91775d.
Branch: master
https://github.com/mongodb/mongo/commit/e34e468d16c9ad6bbe10b7f8ce3a4ee89d74c878

Comment by Githook User [ 03/Feb/20 ]

Author:

{'username': 'vessy-mongodb', 'name': 'Vesselina Ratcheva', 'email': 'vesselina.ratcheva@10gen.com'}

Message: SERVER-45651 Ensure checkReplicaSet sets an explicit writeConcern when running collMod

create mode 100644 jstests/replsets/replsettest_stop_with_default_wc.js
Branch: master
https://github.com/mongodb/mongo/commit/74c4bcd1d353434bb3b89fd7db3604090b91775d

Comment by Kevin Pulo [ 22/Jan/20 ]

Yes, this is appropriate. When we find places in the test infrastructure where it's implicitly assumed that a command will run with the server default writeConcern of { w: 1, wtimeout: 0 } (or similarly for the server default readConcern), then those command invocations should be fixed by explicitly passing the relied-upon writeConcern (and/or readConcern). Thanks for catching this!

Comment by Vesselina Ratcheva (Inactive) [ 21/Jan/20 ]

This was the only one I found. I'm planing on including a (simple) repro test along with the fix for this - hopefully that should tell us if there are other places (but I don't think there will be).

Comment by Robert Guo (Inactive) [ 21/Jan/20 ]

I can't think of any other asynchronous operations that would bypass awaitReplication(). So no (AFAIK).

Comment by Judah Schvimer [ 21/Jan/20 ]

vesselina.ratcheva and robert.guo, to get ahead of this, are there any other commands we need to provide write concerns for?

kevin.pulo, is this the appropriate fix for this behavior?

Generated at Thu Feb 08 05:09:22 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.