[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: |
|
||||||||
| 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 summarycheckReplicaSet 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: |
| Comment by Githook User [ 04/Feb/20 ] |
|
Author: {'name': 'Janna Golden', 'username': 'jannaerin', 'email': 'janna.golden@mongodb.com'}Message: Revert " This reverts commit 74c4bcd1d353434bb3b89fd7db3604090b91775d. |
| Comment by Githook User [ 03/Feb/20 ] |
|
Author: {'username': 'vessy-mongodb', 'name': 'Vesselina Ratcheva', 'email': 'vesselina.ratcheva@10gen.com'}Message: create mode 100644 jstests/replsets/replsettest_stop_with_default_wc.js |
| 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? |