[SERVER-36478] The setFCV command should respect a user-provided wtimeout Created: 06/Aug/18 Updated: 29/Oct/23 Resolved: 10/Oct/18 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Replication, Storage, Upgrade/Downgrade |
| Affects Version/s: | None |
| Fix Version/s: | 4.1.4 |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Neha Khatri | Assignee: | Louis Williams |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | nyc | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||||||
| Sprint: | Storage NYC 2018-10-08, Storage NYC 2018-10-22 | ||||||||||||||||
| Participants: | |||||||||||||||||
| Description |
|
In 4.2, setFeatureCompatibilityVersion command is a chain of operations including the the FCV document update operation and the collMod operations for unique index upgrade. Each of these individual operation within setFCV has its own writeConcern without dependancy on the others. It is required to define a clear dependancy between setFCV and the other operations within setFCV. One example is, setFCV with user supplied writeConcern timeout should propagate this timeout to the writeConcern of collMod operation for unique index upgrade. |
| Comments |
| Comment by Githook User [ 10/Oct/18 ] |
|
Author: {'name': 'Louis Williams', 'email': 'louis.williams@mongodb.com', 'username': 'louiswilliams'}Message: |
| Comment by Eric Milkie [ 29/Aug/18 ] |
|
My decision is that we should use the user-provided timeout for all write concern waits throughout a setFCV command, and that we should continue to honor the user's requested write concern at the conclusion of the setFCV command, as we currently do today. We should also change the behavior of the setFCV command so that it returns ok:false if a write concern timeout occurs during the run of the command. |
| Comment by Ian Whalen (Inactive) [ 24/Aug/18 ] |
|
Assigning to Eric in the next sprint to discuss with others and make a decision on whether we want to stop setFCV from taking a writeconcern timeout or propagate the writeconcern error as Judah suggests. |
| Comment by Ian Whalen (Inactive) [ 17/Aug/18 ] |
|
Discussed in NYC triage meeting but there's still some discussion about what's involved here. Leaving for further discussion when milkie is back. |
| Comment by Alexander Gorrod [ 17/Aug/18 ] |
|
The storage engines team did triage this, but decided to leave it for New York. We believe we know what work is required - so it's a matter of deciding about scheduling now. |
| Comment by Judah Schvimer [ 08/Aug/18 ] |
|
We've had different versions of this discussion over the years. Other relevant tickets include With that context, it seems reasonable to me that setFCV would propagate the user provided wtimeout throughout all write concern waits. That being said, right now WriteConcernErrors are not the same as command errors. Since we currently claim that once setFCV returns success the upgrade is durable, it feels important to me that any WriteConcernError is upgraded to a command error (there may currently be a bug here in |
| Comment by Benety Goh [ 08/Aug/18 ] |
|
We should get some input from tess.avitabile and judah.schvimer. |
| Comment by Neha Khatri [ 08/Aug/18 ] |
|
Conversation from email: neha.khatri said:
benety.goh replied:
|