Operational Defect Database

BugZero found this defect 48 days ago.

MongoDB | 2628179

mongos generates a reply for writes sent by client with w:0

Last update date:

4/2/2024

Affected products:

MongoDB Server

Affected releases:

No affected releases provided.

Fixed releases:

No fixed releases provided.

Description:

Info

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: insert/update/delete bulkWrite In SERVER-83193, we started upgrading the write concerns for these commands by upgrading the opCtx write concern: insert/update/delete bulkWrite change 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.

Top User Comments


Steps to Reproduce


Additional Resources / Links

Share:

BugZero® Risk Score

What's this?

Coming soon

Status

Needs Scheduling

Learn More

Search:

...