MongoS does not report writeConcernError in presence of writeErrors for insert command

XMLWordPrintableJSON

    • Sharding NYC
    • Minor Change
    • ALL
    • v7.0, v6.0, v5.0, v4.4
    • Hide

      1 - Launch a sharded cluster with 3-nodes and 1-shard.

      2 - mongosh into primary mongod and delay replication for all secondary mongod (instructions: https://www.mongodb.com/docs/v6.0/core/replica-set-delayed-member)

      3 - mongosh into mongos and use db "test"

      4 - This step shows the expected writeConcernError:

      [direct: mongos] test> db.runCommand({"insert": "coll", "documents": [{_id: 3}], writeConcern: { w: "majority", j: true, wtimeout: 1000 }})
Uncaught:
MongoWriteConcernError: waiting for replication timed out; Error details: { wtimeout: true, writeConcern: { w: "majority", j: true, wtimeout: 1000, provenance: "clientSupplied" } } at shard01
Additional information: {}
Result: {
  n: 1,
  writeConcernError: {
    code: 64,
    codeName: 'WriteConcernFailed',
    errmsg: 'waiting for replication timed out; Error details: { wtimeout: true, writeConcern: { w: "majority", j: true, wtimeout: 1000, provenance: "clientSupplied" } } at shard01',
    errInfo: {}
  },
  ok: 1,
  '$clusterTime': {
    clusterTime: Timestamp({ t: 1687374253, i: 2 }),
    signature: {
      hash: Binary(Buffer.from("0000000000000000000000000000000000000000", "hex"), 0),
      keyId: Long("0")
    }
  },
  operationTime: Timestamp({ t: 1687374253, i: 2 })
}

      5 - Rerunning the insert command verbatim a second time will yield a duplicate key writeError instead of the expected writeConcernError:

      [direct: mongos] test> db.runCommand({"insert": "coll", "documents": [{_id: 3}], writeConcern: { w: "majority", j: true, wtimeout: 1000 }})
{
  n: 0,
  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 }
    }
  ],
  ok: 1,
  '$clusterTime': {
    clusterTime: Timestamp({ t: 1687374345, i: 1 }),
    signature: {
      hash: Binary(Buffer.from("0000000000000000000000000000000000000000", "hex"), 0),
      keyId: Long("0")
    }
  },
  operationTime: Timestamp({ t: 1687374338, i: 1 })
}
      Show
      1 - Launch a sharded cluster with 3-nodes and 1-shard. 2 - mongosh into primary mongod and delay replication for all secondary mongod (instructions: https://www.mongodb.com/docs/v6.0/core/replica-set-delayed-member ) 3 - mongosh into mongos and use db "test" 4 - This step shows the expected writeConcernError: [direct: mongos] test> db.runCommand({ "insert" : "coll" , "documents" : [{_id: 3}], writeConcern: { w: "majority" , j: true , wtimeout: 1000 }}) Uncaught: MongoWriteConcernError: waiting for replication timed out; Error details: { wtimeout: true , writeConcern: { w: "majority" , j: true , wtimeout: 1000, provenance: "clientSupplied" } } at shard01 Additional information: {} Result: { n: 1, writeConcernError: { code: 64, codeName: 'WriteConcernFailed' , errmsg: 'waiting for replication timed out; Error details: { wtimeout: true , writeConcern: { w: "majority" , j: true , wtimeout: 1000, provenance: "clientSupplied" } } at shard01' , errInfo: {} }, ok: 1, '$clusterTime' : { clusterTime: Timestamp({ t: 1687374253, i: 2 }), signature: { hash: Binary(Buffer.from( "0000000000000000000000000000000000000000" , "hex" ), 0), keyId: Long ( "0" ) } }, operationTime: Timestamp({ t: 1687374253, i: 2 }) } 5 - Rerunning the insert command verbatim a second time will yield a duplicate key writeError instead of the expected writeConcernError: [direct: mongos] test> db.runCommand({ "insert" : "coll" , "documents" : [{_id: 3}], writeConcern: { w: "majority" , j: true , wtimeout: 1000 }}) { n: 0, 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 } } ], ok: 1, '$clusterTime' : { clusterTime: Timestamp({ t: 1687374345, i: 1 }), signature: { hash: Binary(Buffer.from( "0000000000000000000000000000000000000000" , "hex" ), 0), keyId: Long ( "0" ) } }, operationTime: Timestamp({ t: 1687374338, i: 1 }) }
    • Sharding NYC 2023-07-10, Sharding NYC 2023-07-24, Sharding NYC 2023-08-07, Sharding NYC 2023-08-21, Sharding NYC 2023-09-04
    • 4
    • None
    • None
    • None
    • None
    • None
    • None
    • None

      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 })
}

            Assignee:
            Brett Nawrocki
            Reporter:
            Craven Huynh (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            17 Start watching this issue

              Created:
              Updated:
              Resolved: