Uploaded image for project: 'Node.js Driver'
  1. Node.js Driver
  2. NODE-2383

Unordered bulk write reports wrong error indexes

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major - P3
    • Resolution: Fixed
    • Affects Version/s: 3.4.0
    • Fix Version/s: 3.4.1
    • Component/s: None
    • Labels:
      None
    • MongoDB Version:
      4.2.0

      Description

      When doing an unordered bulk write using node driver 3.4.0 and server 4.2.0, if any of the individual operations fail, they are reported in the "writeErrors" array of the result. Each array element has a field "index", which should contain the position of the failed operation in the original bulk write array. However, the index field is set to the position within the writeErrors array in my example.

      Here is the code:

      async function main() {
          client = await require("mongodb").MongoClient("mongodb://localhost:27017")
          await client.connect()
          ref = client.db("test").collection("ref")
          batch = ref.initializeUnorderedBulkOp()
          batch.insert({"_id":1})
          batch.insert({"_id":1})
          batch.insert({"_id":2})
          batch.insert({"_id":2})
          try {
              await batch.execute()
              console.log("success")
          } catch (err) {
              console.log(JSON.stringify(err.writeErrors, null, 2))
          }
          client.close()
      }
      

      When run with a non-existing collection test.ref, the resulting writeErrors array looks like this:

      [
        {
          "code": 11000,
          "index": 0,
          "errmsg": "E11000 duplicate key error collection: test.ref index: _id_ dup key: { _id: 1 }",
          "op": {
            "_id": 1
          }
        },
        {
          "code": 11000,
          "index": 1,
          "errmsg": "E11000 duplicate key error collection: test.ref index: _id_ dup key: { _id: 2 }",
          "op": {
            "_id": 2
          }
        }
      ]
      

      Comparing this to the original request, the failing operations are at position 1 and 3 in the original bulk write, not 0 and 1.

        Attachments

          Activity

            People

            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: