When an $out or $merge operation is targeting writes to a remote node (either in a sharded cluster, or when running on a replica set secondary and targeting writes to the primary), it will promote any writeConcernError received from the remote node into a top-level error. This causes the entire $out/$merge operation to terminate, and we will return an ok:0 response to the client. This behavior is necessary because $out/$merge may target multiple batches of inserts or updates to a remote node, and the current implementation requires that we wait for write concern to be satisfied for each batch individually. We also do not currently use retryable writes internally for each batch of inserts/updates. Therefore, when a writeConcernError occurs, we are unable to retry the write batch, so the entire $out/$merge must terminate.

In contrast, there are some scenarios where an $out/$merge operation is both doing the read and write sides of the operation locally. For instance, this happens in standalone configurations or when targeting the primary node of a single replica set configuration. When all the writes are happening locally, it is possible to perform all of the inserts/updates without waiting for writeConcern, and then wait for writeConcern to be satisfied at the end. As a consequence, the current implementation for standalones and non-shardsvr replica set primaries will fail with a writeConcernError rather than a top-level command error when the writeConcern is not satisfied.

It could be confusing to clients that the format in which the error is reported depends on the topology of the cluster. In order to improve this situation, we should consider guaranteeing that $out/$merge either always return writeConcern errors with the writeConcernError field, or always promote writeConcern errors to top-level command failures.