Commands that take a writeConcern

Docs changes

• runCommand() shell helper should describe writeConcern along with an example.
• We should have an extract file describing writeConcern usage that each command's reference page can include.

Description

All commands, run with runCommand(), that do writes now accept a writeConcern parameter. Special cases are aggregation and mapReduce. Aggregation only accepts a writeConcern when there is a $out stage in the pipeline. MapReduce only accepts a writeConcern when the "out" option is not set to inline (as in when it outputs to a collection).

A full list of commands that accept a writeConcern can be found here: https://docs.google.com/document/d/1AuKO0IgdwUGw9h-PlyIkZqVtSk_vxF74HxntDTXoGdo/edit#heading=h.ulqd0rufx0m2
Additionally, if there is any question about if a command accepts a writeConcern parameter, every command in the server overrides the function "supportsWriteConcern", specifying if it supports writeConcern.

All commands that support writeConcern accept it as a parameter to runCommand(). No changes were made to the shell or its helpers, so depending on how shell helpers handle their arguments, shell helpers may or may not accept a writeConcern parameter. For example, createCollection accepts a writeConcern argument in its options object, but dropCollection does not accept any arguments.

If a writeConcern is supplied to a command that does not accept writeConcern, the command will not execute and will fail.

If an invalid writeConcern is passed to a command that supports writeConcern, behavior depends on the cluster topology. On a standalone server (which accepts writeConcern for journalling purposes), invalid writeConcern arguments will yield a command failure before the command is run. This means that the command will not actually be executed. For failures on replicasets and sharded clusters, the writeConcern validity is only checked after the command is run, and thus the command will still execute on the primary. The primary will just not wait for replication before returning to the user. In this case the user will receive a writeConcernError field in their response.

If the writeConcern fails due to a replication timeout, the failure will occur after the command has executed on the primary, but the data may not be visible on the secondaries yet. The user will receive a writeConcernError field in their response.

Write concern error responses have not changed for commands that already support writeConcern. In most cases, if waiting for writeConcern fails (due to timeout or an invalid writeConcern parameter) the user receives a writeConcernError field in their response in addition to ok: 1. For user management commands where in the past writeConcern errors yielded ok: 0, the command will return a writeConcernError in addition to ok: 0 (same as its behavior in 3.2). Finally, for commands on mongos that do writes on the config servers, the response will contain ok: 0 and will not have a writeConcernError. Commands that do writes to both the shards and config servers will yield ok: 1 if the writeConcern failure occurs on the shards and ok: 0 if it occurs on the config servers.