[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:
Related
related to SERVER-31335 Shell needs an "assert failed with co... Closed
is related to SERVER-37153 assert.commandWorked() should fail wh... Closed
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: SERVER-30879: check for write concern errors on assert.commandWorked
Branch: master
https://github.com/mongodb/mongo/commit/fd6f205a3ab17feec0cc9a0ba2a4baba8627f1f2

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?

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