[GODRIVER-2901] Separate batching, retry, and single-operation execution logic Created: 11/Jul/23  Updated: 17/Jul/23

Status: Backlog
Project: Go Driver
Component/s: Retryability
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Unknown
Reporter: Matt Dale Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to GODRIVER-2579 Incorporate connection pool checkout ... Backlog
is related to GODRIVER-2892 Remove all code that is only required... Closed

 Description   

Currently, all batching, retry, server and connection selection, single-operation execution, and error handling logic are part of the giant 500-line Operation.Execute function. That function is becoming unmaintainable as more and more logic is added to it (e.g. RTT short-circuit, memory buffer reuse, additional error handling, etc). Difficulty maintaining Operation.Execute has also contributed to several bugs (GODRIVER-2677, GODRIVER-2768) and Go driver version retractions (v1.11.0 - v1.11.2).

Refactor Operation.Execute into functions and/or types with separate concerns. For example, it might make sense to create a function and/or type for each of:

  1. Batching
  2. Retry
  3. Single-operation execution

Definition of done:

  • Split Operation.Execute into functions and/or types that separate at least batching, retry, and single-operation execution concerns.
  • Add tests that assert the behavior of each concern individually.


 Comments   
Comment by Matt Dale [ 11/Jul/23 ]

Past attempts at this have been blocked by some issues:

  • GODRIVER-2579 - The current server selection retry logic depends on the operation retry logic. The selected server impacts how batching and retry work, so pulling those concerns apart is impractical to impossible. Making server selection an independently retryable operation would significantly simplify the server selection and error handling logic, reducing the complexity of the separation of concerns refactor.
  • GODRIVER-2892 - The additional code for supporting legacy MongoDB APIs has added to the cost of refactoring the existing code. Now that the Go Driver only needs to support OP_MSG (MongoDB 3.6+), we can remove the legacy logic, reducing the complexity of the separation of concerns refactor.
Generated at Thu Feb 08 08:39:36 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.