[SERVER-36464] Guard against direct writes to the featureCompatibilityVersion document Created: 06/Aug/18  Updated: 06/Dec/22  Resolved: 25/Jun/19

Status: Closed
Project: Core Server
Component/s: Upgrade/Downgrade
Affects Version/s: None
Fix Version/s: None

Type: Task Priority: Major - P3
Reporter: Maria van Keulen Assignee: Backlog - Query Team (Inactive)
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
Assigned Teams:
Query
Participants:

 Description   

Changing the featureCompatibilityVersion by directly modifying the FCV document is unsafe because it circumvents any upgrade/downgrade handling that occurs during the setFCV command. Direct modifications to the FCV document should be disallowed.



 Comments   
Comment by Kaloian Manassiev [ 24/May/19 ]

Passing it to the Query team with the understanding that they own upgrade/downgrade in 4.2

Comment by Maria van Keulen [ 06/Aug/18 ]

In light of kyle.suarez's comment, part of the work for this ticket should be investigating whether it's possible to distinguish user-initiated writes to the FCV document from writes to the FCV document that occur during oplog application.

Comment by Kyle Suarez [ 06/Aug/18 ]

Is this possible because there is a special way the fCV is propagated in a replica set? For the non-materialized views project, we attempted to prevent direct modifications to the system.views collection in SERVER-25890, but it proved to be difficult because we relied on changes to be propagated via the normal replication path (i.e., creations / modifications to views on the primary are replicated as inserts / updates to system.views on secondaries).

Generated at Thu Feb 08 04:43:11 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.