Loading...

XML

Word

Printable

JSON

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
Confidence Status:
None
Work Order:
3

Aha! Reference:
None
Tracking Level:
None
Risk Status:
None
Exec Notes:
None
Goal Name:
None
Goal Link:
None

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

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

Assignee:: Max Hirschhorn
Reporter:: Max Hirschhorn
Participants:: Githook User, Max Hirschhorn
Votes:: 0 Vote for this issue
Watchers:: 1 Start watching this issue

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

Details

Description

Attachments

Issue Links

Activity

People

Dates