SERVER-83193 introduced a behavioral change that I think is likely unintentional.
In general, we seem to equate w:0 ("unacknowledged") writes with fire-and-forget writes (i.e. those with the moreToCome flag set on the OP_MSG request). The drivers spec requires that drivers send unacknowledged writes with the moreToCome flag, and the server test runner (aka legacy shell) will always send w:0 writes as fire-and-forget as well.
Following from that, it stands to reason that the server should not actually generate a command response for any unacknowledged write because the response will never be consumed by a spec-compliant client.
Accordingly, we have mongos logic that skips generating a reply for a write command if it was sent with w:0:
- for insert, update, delete commands, BatchWriteOp::buildClientResponse inspects the write concern
- for bulkWrite command: _populateCursorReply checks isUnacknowledgedBulkWrite which inspects the write concern
mongos must "upgrade" w:0 write concerns when sending child requests to shards in order to see which writes succeed/fail. Previously, this was done by appending an upgraded WC directly to the child requests:
In SERVER-83193, we started upgrading the write concerns for these commands by upgrading the opCtx write concern:
This change means that the checks above that inspect the opCtx write concern when determining whether or not to generate a reply no longer work on mongos (since they observe the "upgraded" write concern) and we still generate a reply for a w:0 write that a spec-compliant client will never actually consume, doing unnecessary work.
Possibly, there could be other issues caused by this as well if we have any other code that relies on being able to inspect the original request's write concern, though I did not find any other instances in a quick search.
This issue was found via the Node driver which was erroneously sending w:0 writes without the moreToCome flag. (NODE-6060)
Reproducer from neal.beeken@mongodb.com:
db.runCommand({ update: 'test', updates: [ { q: { a: 1 }, u: { c: 'c' }, multi: true } ], writeConcern: { w: 0 }, ordered: true })
Assuming this change was unintentional, we should correct it and should also add test(s) for this that cover all of insert, update, delete, bulkWrite since it seems we are missing them.
- is caused by
-
SERVER-83193 Replace deprecated BatchedCommandRequest getters/setters for WC with the ones provided by OperationContext
- Closed
- related to
-
NODE-6060 Set fire-and-forget bit when writeConcern is w: 0
- Closed