[SERVER-37708] Change writeConcern upconversion to majority for internal connections on config servers to instead uassert that the request was sent with majority writeConcern Created: 22/Oct/18 Updated: 06/Dec/22 Resolved: 24/May/19 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | 4.1.4 |
| Fix Version/s: | None |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Esha Maharishi (Inactive) | Assignee: | [DO NOT USE] Backlog - Sharding Team |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Assigned Teams: |
Sharding
|
| Participants: |
| Description |
|
There is at least one known place where a node in the cluster calls a config server command without passing majority writeConcern (where mapReduce with sharded output calls _configsvrShardCollection, which could be fixed by calling CommandHelpers::appendMajorityWriteConcern here), as discovered in this Evergreen patch that removed the upconversion logic entirely. One drawback of replacing the upconversion with a uassert is that our tests may not catch all places where majority writeConcern is not passed, so this may introduce a "breaking change": in the wild, the uassert will be triggered rather than the upconversion applied. |
| Comments |
| Comment by Kaloian Manassiev [ 24/May/19 ] |
|
This looks like a backwards compatibility change, which could destabilize released versions. Given that it is just for discovering if there are cases where we don't send majority write concern, I don't see much value in doing it, so closing. |