RetryPolicy LWT support #1155
Labels
API-breaking
This might introduce incompatible API changes
API-stability
Part of the effort to stabilize the API
area/statement-execution
enhancement
New feature or request
performance
Improves performance of existing features
RetryPolicy should be able to behave differently when a query is LWT. For example, DefaultRetryPolicy should avoid retrying on next host in that case, so that it doesn't break LWT optimization.
To do this, we need to add
isLWT
field toQueryInfo
struct, and adaptDefaultRetryPolicy
to that.Side notes:
QueryInfo
should be marked non-exhaustive, so that we are able to add more fields to it in the future.It could also implement
Default
, or havenew()
method, so that users are able to construct it. User may want to construct it to test their custom policies.Maybe we should split
QueryInfo
intoQueryInfo
, passed to the policy innew_session
(and perhapsretry
? Not sure how the session are used), and containing fields that are bound to the query, likeis_idempotent
orisLWT
.AttemptInfo
containing info about specific attempt, passed todecide_should_retry
. It would contain info about a specific attempt, likeconsistency
or query error.Why? To better utilize type system, documenting that query-related fields can't change between attempts.
The text was updated successfully, but these errors were encountered: