[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: |
|
||||||||
| 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 |
| 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. |