-
Type:
Task
-
Resolution: Fixed
-
Priority:
Major - P3
-
Affects Version/s: None
-
Component/s: None
-
None
-
Query Execution
-
Fully Compatible
-
QE 2026-03-30
-
None
-
None
-
None
-
None
-
None
-
None
-
None
SERVER-102942 removed maxFeatureCompatibilityVersion that was previously in the expression context. We used to set maxFeatureCompatibilityVersion when validateFeaturesAsPrimary was false to try and avoid FCV checks during replication recovery. During replication recovery, we do not need maxFeatureCompatibilityVersion when we are applying oplog entries because we correctly do not check FCV when parsing new query features for views and validators. However we want to confirm in this ticket that there weren't other situations where we relied on maxFeatureCompatibilityVersion.
See TODOs in code. collection_validator_feature_compatibility_version and view_definition_feature_compatibility_version reference validateFeaturesAsPrimary
- is caused by
-
SERVER-102942 Add IncrementalFeatureContext that an operation can use to track incremental rollout features it uses
-
- Closed
-
- is related to
-
SERVER-83754 REGISTER_DOCUMENT_SOURCE_WITH_FEATURE_FLAG should be able to handle upgrade/downgrade
-
- Closed
-
-
SERVER-115394 add $_testFeatureFlagLatest test to view and validator generic FCV tests
-
- Open
-
- related to
-
SERVER-121897 View creation sometimes still permitted while FCV-incompatible view definitions are present
-
- Needs Scheduling
-
-
SERVER-121901 Remove unneeded internalValidateFeaturesAsPrimary flag
-
- Backlog
-