[SERVER-30879] assert.commandWorked() should check for writeConcernError() Created: 29/Aug/17 Updated: 30/Oct/23 Resolved: 20/Mar/18 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Testing Infrastructure |
| Affects Version/s: | None |
| Fix Version/s: | 3.7.4 |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Mathias Stearn | Assignee: | David Bradford (Inactive) |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | tig-assertjs | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||
| Sprint: | TIG 2018-03-12, TIG 2018-03-26 | ||||||||||||
| Participants: | |||||||||||||
| Description |
|
assert.commandWorked({..., w:'majority'}) should imply that the operation succeeded with the necessary write concern. We can have a separate assert.commandWorkedIgnoreWriteConcern() for the few cases where we explicitly want to test the command succeeding but failing to replicate to the specified write concern. |
| Comments |
| Comment by Githook User [ 20/Mar/18 ] |
|
Author: {'email': 'david.bradford@mongodb.com', 'name': 'David Bradford', 'username': 'dbradf'}Message: |
| Comment by Mathias Stearn [ 31/Aug/17 ] |
|
That has always been the behavior. I think the justification was that there is a difference between the command failing and affirmatively not happening vs the command succeeding but failing to replicate in a timely manor. In the later case, the operation may eventually replicate and enter the canonical timeline, while in the former case it never will. However, I don't think this distinction is important to most of our tests. |
| Comment by Max Hirschhorn [ 31/Aug/17 ] |
|
redbeard0531, why does the server respond with ok=1 when there's a write concern error? |