-
Type: Task
-
Resolution: Unresolved
-
Priority: Unknown
-
None
-
Affects Version/s: None
-
Component/s: None
-
None
The steps for executing an operation are roughly as follows:
- verify that the operation-agnostic options provided are valid
- verify that the explicit session is supported and in a valid state if one is provided, or create an implicit session if not
- select a server and check out a connection
- construct the command and validate that none of the options provided are incompatible with the session/server/connection
- send the command to the server
- retry as needed
Amongst these steps is emitting/logging the various command events that occur.
Our current operation execution control flow follows the path of: entry method (e.g. execute_operation) -> execute_operation_with_details -> execute_operation_with_retry -> execute_operation_on_connection. The final method in this process is the most substantial and contains logic to perform various parts of all of the steps listed above. We should refactor our execution code to be more granular and follow the steps listed above more closely. We should also make sure that the executor file is well-documented so that we can maintain an easy-to-follow structure as we continue to add more logic.
Lastly, we should attempt to prioritize the easiest steps in this process first. For example, verifying that the user's write concern is well-formed currently occurs after session creation/server selection/connection checkout, but we can save some time by checking it right off the bat.
- related to
-
RUST-582 Client Side Operations Timeout
- Canceled