As of MongoDB 3.4, error responses from the server include not only the error code and message, but also a stringified representation of the error code, in the codeName field. Drivers should ensure that this code name is accessible from any errors that are returned or exceptions that are raised based on error responses from the server.

Example responses:

MongoDB Enterprise repl0:PRIMARY> db.runCommand(

{insert: "test", documents: []}

)

{ "operationTime" : Timestamp(1524837772, 1), "ok" : 0, "errmsg" : "Write batch sizes must be between 1 and 100000. Got 0 operations.", "code" : 16, "codeName" : "InvalidLength", }

MongoDB Enterprise repl0:PRIMARY> db.runCommand({insert: "test", writeConcern:

{w: 10}

, documents: [{_id: 2}]})
{
"n" : 1,
"opTime" :

{ "ts" : Timestamp(1524837850, 1), "t" : NumberLong(15) }

,
"electionId" : ObjectId("7fffffff000000000000000f"),
"writeConcernError" :

{ "code" : 100, "codeName" : "CannotSatisfyWriteConcern", "errmsg" : "Not enough data-bearing nodes" }

,
"ok" : 1,
"operationTime" : Timestamp(1524837850, 1),
"$clusterTime" : {
"clusterTime" : Timestamp(1524837850, 1),
"signature" :

{ "hash" : BinData(0,"AAAAAAAAAAAAAAAAAAAAAAAAAAA="), "keyId" : NumberLong(0) }

}
}
Note that a writeConcernError document can also contain a codeName embedded within it. No evidence that the documents within the writeErrors array field do the same.