-
Notifications
You must be signed in to change notification settings - Fork 110
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
session: internal request execution API error types refactor #1157
base: main
Are you sure you want to change the base?
Conversation
The name is more fitting, because this function is generic over CQL request kinds. Query is a name for a specific CQL request. Updated the names of variables, and some types that are directly used by this function. Adjusted the documentation of the function.
See the following report for details: cargo semver-checks output
|
Again, query would suggest that we want to execute a CQL QUERY request. New name also clearly tells the user that provided closure can be potentially executed multiple (based on plan and retry session). Documented the function. Renamed ExecuteQueryContext -> ExecuteRequestContext
This is to prevent some unwanted implicit conversions.
This is then converted to `ProtocolError` in UserRequestError::into_query_error().
Adjusted, so the callers now convert QueryResponse to QueryResult.
Notice that into_query_result returns QueryError, and not UserRequestError (as into_non_error_query_response). It's then converted to QueryResult later. This change is required to prepare for further changes (i.e. narrowing the return type of errors passed to LBP, retry policy etc.).
In the next commit, I want to narrow the error type of `do_query` closure to UserRequestError. `do_query` closure for `query` method serializes the values after preparation.
Thanks to that, we will be able to pass the narrower error type to LBP::on_query_failure. Currently, QueryError is passed, but not all of its variants could even be constructed at this stage.
This error will be passed to LoadBalancingPolicy::on_query_failure and to RetrySession::decide_should_retry.
This narrows the error type passed to this function. Thanks to that, we do not have to match against the variants that could not ever be passed there (which was the case for QueryError).
Request is a more fitting name here.
Same as for LBP::on_query_failure, it narrows the type.
cc87b86
to
22c90e4
Compare
v1.1: Rebased on latest #1156 and addressed @Lorak-mmk comments. Most important change is that we replaced |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good.
A suggestion for the future (because this PR is probably not a good place for this): could you re-order variants in UserRequestError so that they match the order in QueryError? Changing the QueryError instead would be fine too - I just think that the variants present in both should appear in the same order in both.
Ref: #519
Depends on: #1156
execute_request_once closure
To narrow the error return types of some important API functions (e.g.
RS::decide_should_retry
andLBP::on_query_failure
), the error type ofexecute_request_once
(previously known asdo_query
) needs to be adjusted as well. A couple of commits at the beginning of this PR do just that. What we achieve, is that we narrow the return error type of the closure fromQueryError
toUserRequestError
.LBP and RetrySession
Both of these traits accept some error and do something based on the error. Before this PR, they would accept a
QueryError
, resulting in matches against variants that could never even be constructed before the call. In this PR, I pub-ified theUserRequestError
, and madeLBP::on_query_failure
andRetrySession::decide_should_retry
accept it instead ofQueryError
.Pre-review checklist
[ ] I have adjusted the documentation in./docs/source/
.Fixes:
annotations to PR description.