Improve TimeOutException handling in retryable reads/writes

XMLWordPrintableJSON

    • Type: Improvement
    • Resolution: Unresolved
    • Priority: Unknown
    • None
    • Component/s: CSOT
    • None
    • Needed
    • Hide

      Summary of necessary driver changes

      •  

      Commits for syncing spec/prose tests
      (and/or refer to an existing language POC if needed)

      •  

      Context for other referenced/linked tickets

      •  
      Show
      Summary of necessary driver changes   Commits for syncing spec/prose tests (and/or refer to an existing language POC if needed)   Context for other referenced/linked tickets  

      Summary

      In retryable read/write we suppose to throw the last server-provided exception. If user enabled CSOT timeout, most likely it will be TimeOutException caused by server returning 

      {ok: 0, code: 50, codeName: "MaxTimeMSExpired", errmsg: "operation time limit exceeded"}
      

      What means the real problem that makes driver to retry the operation will be masked from end user with non-informative generic timeout error.

      We have number of tests that enforces Driver to return timeout exception in such scenario ("timeoutMS applies to whole operation, not individual attempts..."). We should update the tests to verify that the command was retried and assert readable error was throwed.

      Motivation

      Who is the affected end user?

      Users with CSOT timeout configured.

      How does this affect the end user?

      Yes. Throwing TimeOutException from retryable operations could mask the real useful exception.

      If the problem does occur, what are the consequences and how severe are they?

      Hard to investigate problems, as useful error message will be replaced with generic "timeout occurred".

      Is this ticket only for tests?

      Not

      Acceptance Criteria

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

              Assignee:
              Unassigned
              Reporter:
              Oleksandr Poliakov
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

                Created:
                Updated: