Info

When an update with multi: true encounters a WriteConcernError on mongos, we get the following response. Note that the WCE appears in the writeConcernError field: { "nModified" : 2, "n" : 2, "writeConcernError" : { "code" : 64, "codeName" : "WriteConcernFailed", "errmsg" : "Multiple errors reported :: UnsatisfiableWriteConcern: Not enough data-bearing nodes; Error details: { writeConcern: { w: 3, wtimeout: 0, provenance: \"clientSupplied\" } } at shard-rs0 :: and :: UnsatisfiableWriteConcern: Not enough data-bearing nodes; Error details: { writeConcern: { w: 3, wtimeout: 0, provenance: \"clientSupplied\" } } at shard-rs1", "errInfo" : { } }, "ok" : 1, "$clusterTime" : { "clusterTime" : Timestamp(1695235981, 1), "signature" : { "hash" : BinData(0,"AAAAAAAAAAAAAAAAAAAAAAAAAAA="), "keyId" : NumberLong(0) } }, "operationTime" : Timestamp(1695235981, 1) } On the other hand, when using multi: false on a multi-shard cluster (therefore triggering updateOne without shard key), we see that the WCE is placed into writeErrors instead, which is inconsistent with the above. { "nModified" : 0, "n" : 0, "writeErrors" : [ { "index" : 0, "code" : 100, "errmsg" : "Write results unavailable from failing to target a host in the shard shard-rs1 :: caused by :: Command error committing internal transaction :: caused by :: Not enough data-bearing nodes; Error details: { writeConcern: { w: 3, wtimeout: 0, provenance: \"clientSupplied\" } }" } ], "ok" : 1, "$clusterTime" : { "clusterTime" : Timestamp(1695235903, 2), "signature" : { "hash" : BinData(0,"AAAAAAAAAAAAAAAAAAAAAAAAAAA="), "keyId" : NumberLong(0) } }, "operationTime" : Timestamp(1695235903, 2) } Also, when some other server error appears, like a TypeMismatch, the WCE is hidden and only the TypeMismatch is shown. { "nModified" : 0, "n" : 0, "writeErrors" : [ { "index" : 0, "code" : 14, "errmsg" : "Write results unavailable from failing to target a host in the shard shard-rs0 :: caused by :: Cannot apply $inc to a value of non-numeric type. {_id: 1000.0} has the field 'a' of non-numeric type array" } ], "ok" : 1, "$clusterTime" : { "clusterTime" : Timestamp(1695236285, 4), "signature" : { "hash" : BinData(0,"AAAAAAAAAAAAAAAAAAAAAAAAAAA="), "keyId" : NumberLong(0) } }, "operationTime" : Timestamp(1695236285, 2) } See SERVER-81246 which is a ticket for a similar bug on FLE (also uses internal transactions).

Top User Comments

janna.golden commented on Mon, 3 Mar 2025 21:31:01 +0000: If there is a writeError returned from an insert, update, or delete this indicates that the write definitely failed - in the case of writes without a shard key, the commit transactions fails entirely even on the primary (the error is of error category "WriteConcernError", which may be the cause of command/write errors or writeConcernErrors). It's acceptable behavior that writes without a shard key fail in this way. We have tests for updates that would fail, and do report write concern error - I also tested the repro in this comment (perhaps this has been fixed by other work related to this project).

Steps to Reproduce