-
Type:
Task
-
Resolution: Unresolved
-
Priority:
Major - P3
-
None
-
Affects Version/s: 8.1.0-rc0
-
Component/s: Upgrade/Downgrade
-
Catalog and Routing
-
CAR Team 2025-02-17, CAR Team 2025-03-03, CAR Team 2025-03-17
DDLs such as createCollection, renameCollection, collMod, etc. check feature flags during their execution. After they complete running on a primary, they are replicated through the oplog to secondary nodes.
During oplog application, it is a typical pattern for secondaries to call into the same code paths that primaries have used to run the original operation. However, it is currently unsafe to check feature flags during oplog application, because the DDL operation can race with SetFCV, so it is possible that a feature flag that was seen as disabled by the primary is seen as enabled by the secondary, or vice versa (SERVER-91221).
Currently this requires a per-case solution ("The oplog entry itself should tell the secondary how to execute the operation.") and missing this leads to bugs (e.g see SERVER-91610, SERVER-100675).
This ticket will investigate if it is viable and worthwhile to propagate operation FCV through the oplog, so that DDLs running on secondaries can see the same feature flags that the primary saw, eliminating the need for per-case solutions.
- related to
-
SERVER-79269 Invariant that we don't check FCV in oplog application
-
- Open
-
-
SERVER-91221 Catalog and Routing: Audit feature flag checks for unsafe races with setFCV
-
- Closed
-