Support nModified being optional in bulk write response

[lukestephenson]

We saw issues with bulk writes failing to parse the response because nModified appears to be optional. I'm not sure why the mongodb cluster sometimes includes it on the response and other times omits it.

This appears to be handled already by other drivers:

• javascript driver
• go driver

JAVA-5986

[rozza]

Hi @lukestephenson, thanks for the PR - do you have any example code that reproduces this issue?

Ross

[lukestephenson]

Hi @rozza . I wasn't able to come up with a test which replicates this issue. Our CI tests make use of testcontainers and I was never able to see this issue with the tests I have. I'm not sure why.

However, in our deployed environment using an actual mongodb cluster, it was very easy to reproduce when our application ran (and with this change patched into the deployment, it didn't fail). The server details are:

db.version()
8.0.15

The way I debugged this issue was to turn on logging of <logger name="org.mongodb.driver.protocol.command" level="DEBUG" /> and then look at the request / responses from the mongodb cluster. What I observed in the responses is that for a ClientNamespacedWriteModel.replaceOne upsert, sometimes the response includes nModified while other times it does not. For example, here is a snippet of a logged server response:

{
  "cursor": {
    "id": 0,
    "firstBatch": [
      {
        "ok": 1.0,
        "idx": 0,
        "n": 1,
        "nModified": 0,
        "upserted": {
          "_id": {
            "$oid": "68edabcbe0b3c4f338077a30"
          }
        }
      },
      {
        "ok": 1.0,
        "idx": 1,
        "n": 1,
        "upserted": {
          "_id": {
            "$oid": "68edac0dddd3d2b809269344"
          }
        }
      },
     ... MORE RESULTS HERE ...
    ],
    "ns": "admin.$cmd.bulkWrite"
  },
  "nErrors": 0,
  "nInserted": 0,
  "nMatched": 29,
  "nModified": 0,
  "nUpserted": 59,
  "nDeleted": 0,
  "retriedStmtIds": [],
  "ok": 1.0,
  "$clusterTime": {
    "clusterTime": {
      "$timestamp": {
        "t": 1760406567,
        "i": 86
      }
    },
    "signature": {
      "hash": {
        "$binary": {
          "base64": "REMOVED",
          "subType": "00"
        }
      },
      "keyId": REMOVED
    }
  },
  "operationTime": {
    "$timestamp": {
      "t": 1760406567,
      "i": 86
    }
  }
}

Note how the first response includes the nModified flag, while the second does not. The two operations were both of the same type, however they were on different collections.

[lukestephenson]

It's also worth noting we are doing:

val options = ClientBulkWriteOptions.clientBulkWriteOptions().ordered(false).verboseResults(true)

Note that without .verboseResults(true), we were getting an assertion failure here

[rozza]

LGTM

[jyemin]

Note that without .verboseResults(true), we were getting an assertion failure here.

Let's not lose track of this issue. That shouldn't happen.

[rozza]

Thanks @lukestephenson for the PR. Turned out to be a server issue / edge case.

This fix has been merged into main and will be released in due course.

[vbabanin]

It's also worth noting we are doing:

val options = ClientBulkWriteOptions.clientBulkWriteOptions().ordered(false).verboseResults(true)
Note that without .verboseResults(true), we were getting an assertion failure here

Thanks for bringing this to our attention @lukestephenson.

It’s also connected to a server-side issue tracked here: SERVER-113344.
We’re addressing the assertion error in a separate PR: #1835.