-
Type: Bug
-
Resolution: Unresolved
-
Priority: Major - P3
-
None
-
Affects Version/s: None
-
Component/s: None
-
Cluster Scalability
-
ALL
In SERVER-86299, we observed that when doing an update that perform a scatter-gather query on multiple shards, but only writes to a single shard, mongos commits the internal transaction using single-write-shard commit where commitTransaction commands are issued to the read-only shards first, then finally to the write shard. If any of the read-only shards respond with an UnsatisfiableWriteConcern writeConcernError, the final response that a user sees would look like:
{ "nModified" : 0, "n" : 0, "writeErrors" : [ { "index" : 0, "code" : 100, "errmsg" : "Write results unavailable from failing to target a host in the shard test-rs1 :: caused by :: Command error committing internal transaction :: caused by :: Not enough data-bearing nodes; Error details: { writeConcern: { w: 3, j: false, wtimeout: 1000, provenance: \"clientSupplied\" } }" } ], "ok" : 1, "$clusterTime" : { "clusterTime" : Timestamp(1734401410, 27), "signature" : { "hash" : BinData(0,"AAAAAAAAAAAAAAAAAAAAAAAAAAA="), "keyId" : NumberLong(0) } }, "operationTime" : Timestamp(1734401410, 27) }
Granted that there's no actual write that was performed since no commitTransaction got issued to the write shard, and the internal transaction is aborted, is having the UnsatisfiableWriteConcern error in the writeErrors field the correct way of expressing this error to clients?
- related to
-
SERVER-86299 Test and fix FLE2 writeConcernError reporting in sharded writes
- Closed