[Summary] write concern error reporting issues

XMLWordPrintableJSON

    • Type: Bug
    • Resolution: Fixed
    • Priority: Major - P3
    • 8.0.13, 8.2.0, 7.0.26
    • Affects Version/s: None
    • Component/s: None
    • None
    • Cluster Scalability
    • Fully Compatible
    • ALL
    • None
    • None
    • None
    • None
    • None
    • None
    • None

      This ticket serves as a summary and central reference point for a write concern error reporting issue affecting multiple commands. See the linked tickets for the specific fixes implemented for each command.

      Issue Status as of November 19, 2025

      ISSUE DESCRIPTION AND IMPACT

      In some cases, write concern errors may be incorrectly suppressed when:

      • Certain write errors occur, or
      • The create command completes successfully (on sharded clusters only)

      Certain write errors indicate that data is in a definitive state, for example duplicate key errors or schema validation errors. If a write concern error is not returned alongside these errors or with a success response, applications may incorrectly assume that prior writes were durable, which can lead to silent data loss after a primary failover and a rollback.

      This issue can only manifest if ALL of the following are true:

      • Application is running on a standalone replica set using queryable encryption, or on a sharded cluster.
      • A shard or replica set primary undergoes a failover.
      • Locally committed writes are rolled back to ensure consistency with other members in the shard/replica set.

      If a rollback occurs following a primary failover, writes that appeared successful may be lost without user notification.

      Impact Matrix

      Command When WriteConcernError may be dropped Topologies where issue can occur Example error scenario
      Insert Command failure Sharded Cluster

      Replica Set - when using queryable encryption only      		 In a sharded cluster OR when using queryable encryption against a replica set:
      1. User sends an insert using majority writeConcern, receives an OK response, but with a WriteConcernError.
      2. User retries the insert, receives a DuplicateKeyError, but does not receive a WriteConcernError (despite failing write concern).
      3. Rollback occurs. The first insert is rolled back.
      Update Command failure Sharded Cluster

      Replica Set - when using queryable encryption only      		 In a sharded cluster OR when using queryable encryption against a replica set:
      1. User executes collMod to add schema validation using majority writeConcern, e.g. {x: {$exists: true}}. User receives an OK response, but with a WriteConcernError.
      2. User sends a replacement update, where the new doc does not contain a field "x". User receives DocumentValidationFailure, but does not receive a WriteConcernError (despite failing write concern).
      3. Rollback occurs. The collMod that added the schema validation is rolled back. This is an issue because a user would assume that the schema validation creation was majority replicated after receiving a response from the update without a WriteConcernError.
      findAndModify Command failure Sharded Cluster

      Replica Set - when using queryable encryption only      		 Same example as update.
      Ordered Batch Write Command failure Sharded Cluster

      Replica Set - when using queryable encryption only      		 In a sharded cluster OR when using queryable encryption against a replica set:
      1. User sends some ordered batch of 5 write ops using majority writeConcern. The first 3 write ops fail write concern, and the 4th write fails with some write error. Users receives a response containing only the write error.
      2. Rollback occurs. The first 3 write ops are rolled back.
      Unordered Batch Write Command failure Sharded Cluster - only if all write operations fail with write errors

      Replica Set - when using queryable encryption only      		 In a sharded cluster OR when using queryable encryption against a replica set:
      If all writes in the batch fail with write errors, then any write concern errors that have occurred are suppressed.
      1. User executes collMod to add schema validation using majority writeConcern, e.g. {x: {$exists: true}}. User receives an OK response, but with a WriteConcernError.
      2. User issues unordered batch write, where all writes fail with DocumentValidationFailure, and no WriteConcernError (despite failing write concern).
      3. Rollback occurs, the collMod write is rolled back. This is an issue because a user would assume that the schema validation creation was majority replicated after receiving a response from the update without a WriteConcernError.
      Bulk Write Command failure Sharded Cluster - when using queryable encryption OR if the batch contains any updateOne, deleteOne, or findAndModify requests that do not include the shard key in the query

      Replica Set - when using queryable encryption only      		 In a sharded cluster:
      1. User executes collMod to add schema validation using majority writeConcern, e.g. {x: {$exists: true}}. User receives an OK response, but with a WriteConcernError.
      2. User executes bulkWrite where one of the ops is an updateOne that does not specify the shard key in the query. User receives response indicating there was a DocumentValidationFailure, but does not receive a WriteConcernError (despite failing write concern).
      3. Rollback occurs. The collMod that added the schema validation is rolled back. This is an issue because a user would assume that the schema validation creation was majority replicated after receiving a response from the update without a WriteConcernError.
      abortTransaction Command failure Sharded Cluster - when aborting non-prepared transactions, or when aborting a transaction that was previously committed

      Replica Set      		 In a sharded cluster OR against a replica set:
      1. User executes some writes as part of a transaction, and then issues commitTransaction with majority write concern. User receives an OK response, but with a WriteConcernError.
      2. User then sends abortTransaction, and receives the error TransactionCommitted with no WriteConcernError (despite failing write concern).
      3. Rollback occurs. The transaction is entirely rolled back.
      createIndexes Command failure Sharded Cluster In a sharded cluster:
      1. User sends a createIndexes request for some key {b: 1} and name "b_1". User receives an OK response, but with a WriteConcernError.
      2. User sends a createIndexes request for some different key {b: -1} and the same name "b_1". User receives a failed response IndexKeySpecsConflict, but does not receive a WriteConcernError (despite failing write concern). This indicates to the user the first createIndexes was successfully replicated.
      3. Rollback occurs. The first createIndexes is rolled back.
      createCollection Command success Sharded Cluster In a sharded cluster:
      1. User sends create collection request for some nss, "foo". User receives OK response without a WriteConcernError (despite failing write concern).
      2. Rollback occurs. The create is rolled back.

      DIAGNOSIS AND AFFECTED VERSIONS

      MongoDB 4.4.0 ~ 4.4.29, 5.0.0 ~ 5.0.31, 6.0.0 ~ 6.0.26, 7.0.0 ~ 7.0.25, 8.0.0 ~ 8.0.12

      MongoDB 7.0.26, 8.0.13, and all later versions contain fixes for these issues.

      REMEDIATION AND WORKAROUNDS

      If a rollback occurs, users will need to examine the rollback data generated and determine next steps.

      OTHER AFFECTED TOOLS

      Mongosync/Mongorestore/Mongoimport/Compass may mistakenly assume that a document has been majority-committed at the destination if it receives a DuplicateKeyError on retrying an insert. Similarly, compass' import phase (responsible for importing data from CSV or JSON files into the MongoDB database) may assume that documents have been inserted into the collection on receiving a DuplicateKey error, but they were in fact rolled back to maintain consistency without informing users.

      Mongorestore, Mongoimport, and Compass are susceptible only when using a MongoDB Server version that is affected by this issue. Mongosync is susceptible only when the destination cluster for the migration is using a MongoDB Server version that is affected by this issue.

      Original description

            Assignee:
            Janna Golden
            Reporter:
            Janna Golden
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved: