Skip to content
Merged
Show file tree
Hide file tree
Changes from 4 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
9 changes: 6 additions & 3 deletions source/read-write-concern/read-write-concern.md
Original file line number Diff line number Diff line change
Expand Up @@ -399,9 +399,8 @@ rs0:PRIMARY> db.runCommand({insert: "foo", documents: [{x:1}], writeConcern: { w
}
```

Drivers SHOULD parse server replies for a "writeConcernError" field and report the error only in the command-specific
helper methods for commands that write, from the list above. For example, helper methods for "findAndModify" or
"aggregate" SHOULD parse the server reply for "writeConcernError".
Drivers MUST parse server replies for a "writeConcernError" field and report the error from all driver methods that
accept a `WriteConcern`.
Comment thread
kevinAlbs marked this conversation as resolved.
Resolved

Drivers SHOULD report writeConcernErrors however they report other server errors: by raising an exception, returning
"false", or another idiom that is consistent with other server errors. Drivers SHOULD report writeConcernErrors with a
Expand Down Expand Up @@ -504,6 +503,8 @@ Below are English descriptions of other items that should be tested:

1. Commands supporting a write concern MUST NOT send the default write concern to the server.
2. Commands supporting a write concern MUST send any non-default write concern to the server in the command.
3. Commands supporting a write concern MUST report a `writeConcernError` returned in the server reply from
Comment thread
GromNaN marked this conversation as resolved.
Resolved
command-specific helper methods.

## Reference Implementation

Expand All @@ -521,6 +522,8 @@ instance, we send it.

## Changelog

- 2026-10-23: Require drivers to report `writeConcernError`s.

- 2026-06-17: Remove pre-4.2 version references.

- 2026-05-04: Describe how `readConcern.afterClusterTime` is used in causally-consistent sessions on reads and writes.
Expand Down
7 changes: 7 additions & 0 deletions source/read-write-concern/tests/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -42,6 +42,13 @@ have the following keys:
- `isServerDefault:` Indicates whether the read or write concern is considered the server's default.
- `isAcknowledged:` Indicates if the write concern should be considered acknowledged.

### Write Concern Errors

These tests check that drivers report a `writeConcernError` returned in an `ok: 1` server reply for each driver method
that supports setting a write concern.

The tests utilize the [Unified Test Format](../../unified-test-format/unified-test-format.md).

### Operation

These tests check that the default write concern is omitted in operations.
Expand Down
142 changes: 142 additions & 0 deletions source/read-write-concern/tests/write-concern-errors/aggregate.json

Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.

Original file line number Diff line number Diff line change
@@ -0,0 +1,67 @@
description: write-concern-errors-aggregate

schemaVersion: "1.0"

createEntities:
- client:
id: &client0 client0
useMultipleMongoses: false
- database:
id: &database0 database0
client: *client0
databaseName: &database_name write-concern-errors-tests
- collection:
id: &collection0 collection0
database: *database0
collectionName: &collection_name coll

initialData:
Comment thread
kevinAlbs marked this conversation as resolved.
Resolved
- collectionName: *collection_name
databaseName: *database_name
documents:
- { _id: 1, x: 11 }
- { _id: 2, x: 22 }

tests:
- description: aggregate with $out reports a writeConcernError
operations:
- name: failPoint
object: testRunner
arguments:
client: *client0
failPoint:
configureFailPoint: failCommand
mode: { times: 1 }
data:
failCommands: [ aggregate ]
writeConcernError: &write_concern_error
code: 79
codeName: UnknownReplWriteConcern
- name: aggregate
object: *collection0
arguments:
pipeline:
- $match: { _id: { $gt: 1 } }
- $out: "aggregate_out"
expectError: &expect_write_concern_error
errorCode: 79

- description: aggregate with $merge reports a writeConcernError
operations:
- name: failPoint
object: testRunner
arguments:
client: *client0
failPoint:
configureFailPoint: failCommand
mode: { times: 1 }
data:
failCommands: [ aggregate ]
writeConcernError: *write_concern_error
- name: aggregate
object: *collection0
arguments:
pipeline:
- $match: { _id: { $gt: 1 } }
- $merge: { into: "aggregate_merge" }
expectError: *expect_write_concern_error

Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.

Original file line number Diff line number Diff line change
@@ -0,0 +1,45 @@
description: write-concern-errors-bulkWrite

schemaVersion: "1.0"

createEntities:
- client:
id: &client0 client0
useMultipleMongoses: false
- database:
id: &database0 database0
client: *client0
databaseName: write-concern-errors-tests
- collection:
id: &collection0 collection0
database: *database0
collectionName: coll

initialData:
- databaseName: write-concern-errors-tests
collectionName: coll
documents: []

tests:
- description: bulkWrite reports a writeConcernError
operations:
- name: failPoint
object: testRunner
arguments:
client: *client0
failPoint:
configureFailPoint: failCommand
mode: { times: 1 }
data:
failCommands: [ insert ]
writeConcernError:
code: 79
codeName: UnknownReplWriteConcern
- name: bulkWrite
object: *collection0
arguments:
requests:
- insertOne:
document: { _id: 3, x: 33 }
expectError:
isError: true
Comment on lines +39 to +40

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note: the unified test runner spec doesn't currently support asserting on error codes for bulk errors. The purpose of these tests is to ensure that drivers aren't swallowing write concern errors, so it should be sufficient in these cases just to assert that an error was returned.

Comment thread
isabelatkinson marked this conversation as resolved.
Resolved
Loading
Loading