[COMPASS-7133] Investigate changes in SERVER-78311: mongos does not report writeConcernError in presence of writeErrors for insert command Created: 21/Aug/23  Updated: 24/Jan/24  Resolved: 22/Aug/23

Status: Closed
Project: Compass
Component/s: None
Affects Version/s: None
Fix Version/s: No version

Type: Investigation Priority: Minor - P4
Reporter: Backlog - Core Eng Program Management Team Assignee: Unassigned
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
depends on SERVER-78311 mongos does not report writeConcernEr... Closed
Documentation Changes: Not Needed

 Description   
Original Downstream Change Summary

Previously, mongos would not return the writeConcernError field for insert/update/delete operations if there was also a writeError and the writes were ordered (unordered writes would return both the writeError and writeConcernError as long as at least one write succeeded).

Now, writeConcernErrors are always returned (alongside any writeErrors), regardless of how many writes succeeded and their being ordered or unordered.

Description of Linked Ticket

mongos does not report writeConcernError in presence of writeErrors.

This behavior is unexpected because it is different from the behavior of mongod which report both writeConcernError and writeErrors:

shard01 [direct: primary] test> db.runCommand({"insert": "coll", "documents": [{_id: 3}], writeConcern: { w: "majority", j: true, wtimeout: 1000 }})
Uncaught:
MongoWriteConcernError: waiting for replication timed out
Additional information: {
  wtimeout: true,
  writeConcern: {
    w: 'majority',
    j: true,
    wtimeout: 1000,
    provenance: 'clientSupplied'
  }
}
Result: {
  n: 0,
  electionId: ObjectId("7fffffff0000000000000001"),
  opTime: { ts: Timestamp({ t: 1687374618, i: 1 }), t: Long("1") },
  writeErrors: [
    {
      index: 0,
      code: 11000,
      errmsg: 'E11000 duplicate key error collection: test.coll index: _id_ dup key: { _id: 3 }',
      keyPattern: { _id: 1 },
      keyValue: { _id: 3 }
    }
  ],
  writeConcernError: {
    code: 64,
    codeName: 'WriteConcernFailed',
    errmsg: 'waiting for replication timed out',
    errInfo: {
      wtimeout: true,
      writeConcern: {
        w: 'majority',
        j: true,
        wtimeout: 1000,
        provenance: 'clientSupplied'
      }
    }
  },
  ok: 1,
  lastCommittedOpTime: Timestamp({ t: 1687371016, i: 1 }),
  '$clusterTime': {
    clusterTime: Timestamp({ t: 1687374623, i: 1 }),
    signature: {
      hash: Binary(Buffer.from("0000000000000000000000000000000000000000", "hex"), 0),
      keyId: Long("0")
    }
  },
  operationTime: Timestamp({ t: 1687374618, i: 1 })
}



 Comments   
Comment by PM Bot [ 24/Jan/24 ]

Fix Version updated for upstream SERVER-78311:
7.1.0-rc0, 7.0.6, 6.0.14

Comment by PM Bot [ 22/Jan/24 ]

Fix Version updated for upstream SERVER-78311:
7.1.0-rc0, 7.0.6

Comment by Maurizio Casimirri [ 22/Aug/23 ]

Does not affect devtools

Comment by PM Bot [ 21/Aug/23 ]

Fix Version updated for upstream SERVER-78311:
7.1.0-rc0

Generated at Wed Feb 07 22:45:29 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.