FeatureCompatibility should be an independent ServiceContext decoration

XMLWordPrintableJSON

    • Type: Improvement
    • Resolution: Unresolved
    • Priority: Minor - P4
    • None
    • Affects Version/s: None
    • Component/s: None
    • None
    • Replication
    • None
    • None
    • None
    • None
    • None
    • None
    • None

      We define FeatureCompatiblity here. However, there are some immediate downsides:

      • Checks that reference the version need to write out ServerGlobalParams::FeatureCompatibility instead of simply FeatureCompatiblity.
      • mutableFeatureCompatibility is directly exposed.
      • Our default value does not match our reset value, implying that the state can be accessible but unset. This would be more intuitive if we could provide optionality via either a pointer or an optional.

            Assignee:
            [DO NOT USE] Backlog - Replication Team
            Reporter:
            Benjamin Caimano (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

              Created:
              Updated: