Uploaded image for project: 'Drivers'
  1. Drivers
  2. DRIVERS-2764

Errata in pseudo code for retryable reads specification

    • Type: Icon: Improvement Improvement
    • Resolution: Fixed
    • Priority: Icon: Minor - P4 Minor - P4
    • None
    • Component/s: CSOT
    • None
    • Not Needed

      Summary

      What is the problem or use case, what are we trying to achieve?

      It has been discovered that the pseudo-code provided in the documentation for the retryable reads is not aligned with the specified behavior of prose specification.

      The specified prose specification behavior, in short, is as follows:

      1. If the initial request fails, a retry attempt is initiated.
      2. If this second attempt fails, we verify if CSOT is enabled, and subsequently perform another, second attempt. In case CSOT is not enabled, an error is expected to be thrown.

      However, the pseudo-code within the specification suggests a different approach. It currently demonstrates only one executeCommand followed by a timeout check leading to indefinite number of attempts if CSOT is not enabled.

      This situation appears to be similar to what was previously addressed in the retryable writes specifications DRIVERS-2695.

      Motivation

      Who is the affected end user?

      Who are the stakeholders?
      This affects the readers of the specification because the pseudo code disagrees with the prose spec.

      How does this affect the end user?

      Are they blocked? Are they annoyed? Are they confused?
      This is not a blocker – rather a point of confusion.

      How likely is it that this problem or use case will occur?

      Main path? Edge case?

      This problem will only occur for driver developers who are very closely inspecting the specification, perhaps during implementation or when debugging this path in a driver.

      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?

      Worst case scenario is inconsistencies in how drivers handle retryable reads due to ambiguities in the pseudo code for the specification.

      Is this issue urgent?

      Does this ticket have a required timeline? What is it?

      Not urgent, no timeline.

      Is this ticket required by a downstream team?

      Needed by e.g. Atlas, Shell, Compass?

      No

      Is this ticket only for tests?

      Does this ticket have any functional impact, or is it just test improvements?

      No, just the specification pseudo code.

      Acceptance Criteria

      What specific requirements must be met to consider the design phase complete?

      The prose spec and the pseudo code spec need to logically agree with each other.

            Assignee:
            shane.harvey@mongodb.com Shane Harvey
            Reporter:
            slav.babanin@mongodb.com Slav Babanin
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved: