-
Type:
Bug
-
Resolution: Works as Designed
-
Priority:
Unknown
-
None
-
Affects Version/s: None
-
Component/s: Command Logging and Monitoring, Retryability
-
None
-
(copied to CRM)
-
🔵 Done
-
Java Drivers
-
None
-
None
-
None
-
None
-
None
-
None
The retryable writes and command logging specifications seem in conflict for write concern errors. As the retryable writes spec states:
If the first attempt of a retryable write operation encounters a retryable error, drivers MUST fire a CommandFailedEvent and emit a "command failed" log message for the retryable error and fire a separate CommandStartedEvent and "command succeeded" log message when executing the subsequent retry attempt. Note that the second CommandStartedEvent and "command succeeded" log message may have a different connectionId, since a writable server is reselected for the retry attempt.
However, the command logging spec states:
Commands that executed on the server and return a status of { ok: 1.0 } are considered successful commands and MUST generate a CommandSucceededEvent and "command succeeded" log message. Commands that have write errors are included since the actual command did succeed, only writes failed.
...
Rationale:
1. Why are commands with { ok: 1 } treated as successful and { ok: 0 } as failed?The specification is consistent with what the server deems as a successful or failed command and reports this as so. This also allows for server changes around this behaviour in the future to require no change in the drivers to continue to be compliant.
The command listener API is responsible only for receiving and handling events sent from the lowest level of the driver, and is only about informing listeners about what commands are sent and what replies are received. As such, it would be innappropiate at this level for a driver to execute custom logic around particular commands to determine what failure or success means for a particular command. Implementers of the API are free to handle these events as they see fit, which may include code that further interprets replies to specific commands based on the presence or absence of other fields in the reply beyond the ok field.
- related to
-
DRIVERS-3296 Clarify expected behavior for command logging, retryable writes and write concern errors
-
- Needs Triage
-