-
Type: Bug
-
Resolution: Fixed
-
Priority: Minor - P4
-
Affects Version/s: None
-
Component/s: Testing Infrastructure
-
None
-
Fully Compatible
-
ALL
-
v4.4
-
Execution Team 2021-01-25
-
47
The changes from SERVER-36718 had reintroduced the TestData.forceValidationWithFeatureCompatibilityVersion option so that the jstestfuzz (mutational) fuzzer could upgrade the feature compatibility version before running the validate command. This is useful because certain versions of MongoDB have the validate command intentionally fail in last-lts FCV to allow users to be completely confident about downgrading.
It appears we forgot to change 4.2 -> 4.4 in the jstestfuzz*.yml test suites during the 4.4 release cycle. Observe that both the 4.2 and 4.4 branches are currently forcing the FCV to 4.2. Instead, the 4.4 branch should be forcing the feature compatibility version to 4.4. This hasn't been an issue because there isn't a difference in validate behavior on 4.4, and that'll likely be why the skipFCV concept from b45c07c as part of SERVER-51333 is safe on the 4.4 branch.
However, this in turn led us to change 4.2 -> 4.4 in c593d0f as part of SERVER-46323 when it should really be 4.9 on the master branch now.
- is related to
-
SERVER-51333 setFeatureCompatibilityVersion should fail when downgrading from FCV 4.4 to FCV 4.2 with long collection names present
- Closed
-
SERVER-36718 Validation hook should upgrade before validating index consistency
- Closed
-
SERVER-46323 Update FCV constants throughout server code following 4.4 branch
- Closed
- related to
-
SERVER-53886 jstestfuzz (mutational) fuzzer is forcing latest FCV during validate in multiversion tests
- Closed
-
SERVER-52231 add timeseries to all-features builders
- Closed
-
SERVER-56961 [v4.4] Ensure cluster is in FCV 4.4 while running FuzzerRestoreClusterSettings hook
- Closed
-
SERVER-57557 [v4.4] Support running checkFCV() shell helper with mongos connection
- Closed