Loading...

XML

Word

Printable

JSON

Details

Type: Task
Resolution: Fixed
Priority: Major - P3
Fix Version/s: 4.2.18, 4.4.7
Affects Version/s: None
Component/s: Testing Infrastructure
Labels:
- sharding-wfbf-day

Backwards Compatibility:
Fully Compatible
Backport Requested:

v4.2
Sprint:
Sharding 2021-06-14
Linked BF Score:
45

Description

The changes from c0142cd as part of ~~SERVER-56961~~ made it so the FuzzerRestoreClusterSettings hook first restores the feature compatibility version to latestFCV. When a previous upgrade or downgrade was interrupted, the setFeatureCompatibilityVersion command is run to finish the FCV upgrade or downgrade and then the featureCompatibilityVersion server parameter and document is read to affirm the FCV upgrade or downgrade completed successfully. mongos doesn't report a featureCompatibilityVersion server parameter and so the withFCV() function throws in this case.

https://github.com/mongodb/mongo/blob/e92664940640287874bf6d08940df26fee7bc2b8/jstests/libs/with_fcv.js#L74

Attachments

Issue Links

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-53359 jstestfuzz (mutational) fuzzer is forcing last-lts FCV during validate instead of latest

Closed

SERVER-56961 [v4.4] Ensure cluster is in FCV 4.4 while running FuzzerRestoreClusterSettings hook

Closed

related to

SERVER-59158 Support running checkFCV() shell helper with mongos connection

Closed

Activity

People

Assignee:: Max Hirschhorn

Reporter:: Max Hirschhorn

Participants:: Githook User, Max Hirschhorn

Votes:: 0 Vote for this issue

Watchers:: 1 Start watching this issue

Dates

Created:: Jun 09 2021 02:19:24 AM UTC

Updated:: Oct 29 2023 09:52:26 PM UTC

Resolved:: Jun 10 2021 12:17:51 AM UTC