Description

Description:

Prior to this patch, mongod and mongos would reject an aggregate command that as an attached writeConcern if the agg pipeline did not contain either a $out or $merge stage. With this patch we will now accept a writeConcern for any aggregate pipeline, though it will be ignored if that pipeline is not performing writes.

Not sure if we have documentation that has to change for the above, but wanted to flag just in case.

Engineering Ticket Description:

If a command accepts a write concern, it will always call waitForWriteConcern, no matter if and how it fails. The only question is what OpTime it waits for. If no write was attempted (and consequently the GlobalLockAcquisitionTracker did not move forward the client opTime), we will simply wait for write concern on the client opTime from before the command began. The client opTime may be null, in which case we don't do any waiting, or may already be committed in which we also do no waiting: https://github.com/mongodb/mongo/blob/0bc90017e2563ed7432d56051483763c91d28025/src/mongo/db/service_entry_point_mongod.cpp#L77-L88
If there was a previous uncommitted write on the client, however, we end up waiting for write concern on the previous write, even if the current command received a parse error and should do no waiting. Alternatively, if that previous write was in a previous term, waitForWriteConcern will fail here instead of waiting on it or skipping waiting entirely: https://github.com/mongodb/mongo/blob/0bc90017e2563ed7432d56051483763c91d28025/src/mongo/db/repl/replication_coordinator_impl.cpp#L1489-L1496. In the case where no write was even attempted, rather than wait on the previous write, we should not call waitForWriteConcern at all and just return early. This will prevent waiting on previous writes when unnecessary and failing commands unnecessarily when they shouldn't need to wait for write concern at all.

There is an assumption here that if we do not attempt to take the GlobalLock at any point then we should not wait for write concern at all. This is not always true, such as with retryable writes retrying successful operations(SERVER-33475), in which case those commands should push the client OpTime forwards themselves to ensure we wait on the proper opTime.

Scope of changes

Impact to Other Docs

MVP (Work and Date)

Resources (Scope or Design Docs, Invision, etc.)