-
Type:
Task
-
Resolution: Unresolved
-
Priority:
Unknown
-
None
-
Component/s: Command Logging and Monitoring, Retryability
-
None
-
Needed
Summary
The Command logging and monitoring specification and retryable writes specification appear to be at odds, regarding retryable write concern errors.
Motivation
Who is the affected end user?
Potentially any user with retryable writes and command listeners and write concern errors.
How does this affect the end user?
Confusing as to how to tally the retryable writes in the logs.
How likely is it that this problem or use case will occur?
Edge case
If the problem does occur, what are the consequences and how severe are they?
Minor annoyance at a log message? Performance concern? Outage/unavailability? Failover can't complete?
Is this issue urgent?
No
Is this ticket required by a downstream team?
N/A
Is this ticket only for tests?
Potentially or the specification needs to clarify this edge case.
Acceptance Criteria
Confirmation of the expected behaviour
Detail
The retryable writes specification 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 and monitoring specification 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.
These appear to be in conflict. To add to the confusion there is an explicit test in the Command logging and monitoring specification, that expects a retryable write concern error to issue a CommandSucceeded event for the write concern failure and then another CommandSucceeded event on the successful retry.
What is the expected command logging behavior in this scenario?
- is related to
-
JAVA-5875 Command Logging retryable writes not to spec
-
- Closed
-