Prevent concurrent enablement of feature flags while upgrading FCVs after branch cut

XMLWordPrintableJSON

    • Type: Task
    • Resolution: Fixed
    • Priority: Major - P3
    • 7.3.0-rc0
    • Affects Version/s: None
    • Component/s: None
    • None
    • Replication
    • Fully Compatible
    • v7.2
    • Repl 2023-10-02, Repl 2023-10-16, Repl 2023-10-30, Repl 2023-11-13, Repl 2023-11-27, Repl 2024-01-08
    • None
    • None
    • None
    • None
    • None
    • None
    • None

      While I was investigating the redness from the FCV upgrade to 7.2, SERVER-57414 was merged into master, which toggled a feature flag on master. This happened after the 7.1 branch cut but before master was tagged with 7.2.

       

      This caused a significant amount of redness since tests for that feature flag were essentially enabled for clusters with FCV >= 7.1. However, the future git tag variant has lastContinuous = 7.1, and it attempted to get the 7.1 binary by pulling from evergreen. This binary is obtained from the v7.1 branch, which did not yet have the feature flag enabled. As a result, all tests relevant to that feature flag were failing.

       

      This should not be an issue if rapid releases were working as expected and the FCV upgrade happens soon after branch cut. But if anything goes wrong again in the future, we could run into a similar issue.

      As a result, we should block any new feature flags from being enabled between branch cut and upgrading FCV constants. This may not be worthwhile to enforce programmatically, but we should consider adding this to the feature flag ReadMe.

            Assignee:
            Xuerui Fa
            Reporter:
            Xuerui Fa
            Votes:
            0 Vote for this issue
            Watchers:
            10 Start watching this issue

              Created:
              Updated:
              Resolved: