[SERVER-34601] dassert rather than invarianting when attempting to access uninitialized featureCompatibilityVersion Created: 20/Apr/18  Updated: 06/Dec/22  Resolved: 24/Apr/18

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 - Storage Execution Team
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
related to SERVER-34600 getParameter for featureCompatibility... Closed
Assigned Teams:
Storage Execution
Participants:

 Description   

Presently, our featureCompatibilityVersion getter will invariant that the parameter has been explicitly initialized. However, given the possibility of un-tested featureCompatibilityVersion access scenarios (see SERVER-34600), it might be better to dassert instead so a user cannot crash non-debug servers when accessing the fCV.



 Comments   
Comment by Maria van Keulen [ 24/Apr/18 ]

Per a discussion with milkie, I will close this ticket as Won't Fix. We would like to keep the invariant because it helps avoid misuse of getVersion() to read the fCV before it is initialized, and we believe it is unlikely this invariant will cause enough of a usability problem to justify its removal.

Comment by Andy Schwerin [ 23/Apr/18 ]

Seems suspicious. If it's OK to observe uninitialized FCV, it shouldn't crash debug builds. Also, people tend to forget that dasserts don't equate to runtime guarantees on release builds.

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