-
Notifications
You must be signed in to change notification settings - Fork 111
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
errors: narrow error types accepted by HistoryListener
#1159
base: main
Are you sure you want to change the base?
Conversation
See the following report for details: cargo semver-checks output
|
6a52f4d
to
71539ec
Compare
scylla/src/transport/errors.rs
Outdated
/// Failed to execute a retriable user request. | ||
#[derive(Error, Debug, Clone)] | ||
#[non_exhaustive] | ||
pub enum RetriableRequestError { |
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.
❓ What does it mean for a user request to be retriable or not? When a request is non-retriable?
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.
From a way this error type is used, I understand that it encompasses all retry attempts of a request, whereas UserRequestError
is returned from a single retry attempt. Correct?
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.
🤔 Something is not yes with the naming of this error, or at least the docstring is too terse, because it sounds a bit vague. Unfortunately, I don't have an idea how to fix this. As this type is user-facing, we should definitely make it clearer.
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.
I also dislike this name. I just couldn't come up with anything better. My only idea is to rename UserRequestError
-> [User]RequestAttemptError
(I like this name, because it suggests that it's an error of a single attempt). Then we could use UserRequestError
name instead of RetriableRequestError
.
What do you think of TimeoutableRequestError
name (introduced in this PR)? I'm not sure if you reached the commit that introduces it - this enum simply represents either a request timeout, or a request failure (current RetriableRequestError
). I wonder if there is a better name for this one as well.
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.
My only idea is to rename
UserRequestError
->[User]RequestAttemptError
(I like this name, because it suggests that it's an error of a single attempt). Then we could useUserRequestError
name instead ofRetriableRequestError
.
Sounds good, let's do that.
What do you think of
TimeoutableRequestError
name (introduced in this PR)? I'm not sure if you reached the commit that introduces it - this enum simply represents either a request timeout, or a request failure (currentRetriableRequestError
). I wonder if there is a better name for this one as well.
MaybeTimeoutedRequestError
is one idea that I've had, but it's not ideal, too.
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.
Reordered the variants with respect to the moment corresponding error can arise at during request execution.
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.
New name clearly suggests that this is an error that occurred during a single attempt of a request.
Introduced new error type and adjusted session.rs, speculative_execution module and iterator module to this type. This error represents a definite request failure (after potential retries).
Introduced: - RequestTimeout(std::time::Duration) - for requests that timed out with provided client timeout - SchemaAgreementTimeout(std::time::Duration) - for schema agreement timeouts
This represents either a request failure, or a request timeout. It's created to narrow the type passed to history listener.
- `log_attempt_error` will now accept an error representing a single request failure - namely `UserRequestAttemptError` - `log_query_error` will now accept an error representing a timeoutable request run failure. Compared to `UserRequestAttempt`, it additionally can contain information about an empty plan error, timeout error etc.
71539ec
to
d7c8c96
Compare
v2:
|
Ref: #519
Depends on #1157. Start review from
errors: rename UserRequestError -> UserRequestAttemptError
.New error types and variants
UserRequestAttemptError
It's
UserRequestError
, but renamed. Represents a failure of a single attempt.UserRequestError (reintroduced)
Error type returned by
run_request_spectulative_fiber
. It represents either a definite request failure - last attempt error, connection pool error, or an empty plan error.Replaced QueryError::RequestTimeout
This error variant was not good for 2 reasons:
I decoupled this variant into two separate variants that provide more context.
TimeoutableRequestError (any idea if there is a more fitting name???)
This is a simple wrapper over new
UserRequestError
with additionalRequestTimeout
variant. This error type is only created to narrow the type of errors passed toHistoryListener::log_query_error
.HistoryListener
Narrowed error types passed to log_query_error and log_attempt_error.
log_query_error
now acceptsTimeoutableRequestError
.log_attempt_error
now acceptsUserRequestAttemptError
(representing an error of a single attempt).Replaced "query" mentions with "request"
I did the replacement in trait methods, docstrings, tests etc. I tried to break the changes into multiple commits.
Pre-review checklist
[ ] I added relevant tests for new features and bug fixes.[ ] I have adjusted the documentation in./docs/source/
.Fixes:
annotations to PR description.