[SERVER-31335] Shell needs an "assert failed with code" function that works for any command response Created: 29/Sep/17  Updated: 30/Oct/23  Resolved: 12/Jan/18

Status: Closed
Project: Core Server
Component/s: Testing Infrastructure
Affects Version/s: None
Fix Version/s: 3.7.1

Type: Improvement Priority: Major - P3
Reporter: Kyle Suarez Assignee: Kevin Albertson
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
is duplicated by SERVER-32717 retryable_writes_mmap.js should use a... Closed
Problem/Incident
causes SERVER-32778 Fix perf regression on shell assertio... Closed
Related
is related to SERVER-30879 assert.commandWorked() should check f... Closed
Backwards Compatibility: Minor Change
Sprint: TIG 2018-1-15, TIG 2018-1-29
Participants:
Linked BF Score: 0

 Description   

I'm writing tests that use a variety of different commands and need to assert that they all fail with a particular code. However, the experience is extremely frustrating because the existing assert helpers all require a particular response format, and can't be used uniformly throughout:

  • Error responses with a code field are caught by assert.commandWorked()
  • Error responses with writeError are caught by assert.writeError()
  • I have no idea if anyone can handle the plural writeErrors generated when using the bulk API
  • Any other error response format I'm missing?

I would be very happy if we had one magic function that just "did the right thing" based on the response type / format.



 Comments   
Comment by Kevin Albertson [ 24/Jan/18 ]

The new changes to assert.commandWorked have it better support different types that may be returned in shell helpers. Examples:

// Raw command response
assert.commandWorked(db.runCommand({ping: 1}))
 
// WriteResult
assert.commandWorked(db.coll.insert({}))
 
// BulkWriteResult
assert.commandWorked(db.coll.insert([{},{}]))
 
// WriteCommandError
assert.commandWorked(db.coll.insert({}, {writeConcern: {"bad": 1}})) // throws
 
// CRUD result (not really necessary since it throws on error)
assert.commandWorked(db.coll.insertOne({}))

It also handles error types that may be thrown and caught (WriteError/BulkWriteError/Error) which some of our jstests do catch and assert on (example).

Some more examples can be found in shell_cmd_assertions.js.

Comment by Githook User [ 16/Jan/18 ]

Author:

{'email': 'kevin.albertson@10gen.com', 'name': 'Kevin Albertson', 'username': 'kevinAlbs'}

Message: SERVER-31335 fix assert in retryable_writes_mmap
Branch: master
https://github.com/mongodb/mongo/commit/8f4e5f800169e7825bbcde376904a8b65aa52e27

Comment by Kyle Suarez [ 12/Jan/18 ]

Amazing work, thanks kevin.albertson!

Comment by Kevin Albertson [ 12/Jan/18 ]

The new behavior is that assert.commandWorked, assert.commandFailed, and assert.commandFailedWithCode now account for write errors, and also handle the write wrapper types more consistently based on the different ways the shell returns/throws results: WriteResult, WriteError, BulkWriteResult, BulkWriteError, a raw command response, or an Error object with a code property.

assert.writeErrorWithCode has also been updated to handle multiple writeErrors. It asserts that one of the write errors has the expected code. And assert.commandWorkedIgnoringWriteErrors has been introduced.

Comment by Githook User [ 11/Jan/18 ]

Author:

{'email': 'kevin.albertson@10gen.com', 'name': 'Kevin Albertson', 'username': 'kevinAlbs'}

Message: SERVER-31335 cmd assertions check write errors
Branch: master
https://github.com/mongodb/mongo/commit/5e28f4a35229422ec48ba7611e67b414b0eeb77f

Comment by Max Hirschhorn [ 26/Dec/17 ]

I think it would be fine to change the behavior of assert.commandWorked() to do this since the handling around writeError and writeErrors is tied to checking if the parameter is an instance of WriteResult, BulkWriteResult, or WriteCommandError. We should probably defer handling writeConcernError to SERVER-30879 and then schedule that ticket in the near term.

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