Skip to content

RetryPolicy LWT support #1155

Open
Open
@Lorak-mmk

Description

@Lorak-mmk

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 to QueryInfo struct, and adapt DefaultRetryPolicy 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 have new() 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 into

  • QueryInfo, passed to the policy in new_session (and perhaps retry? Not sure how the session are used), and containing fields that are bound to the query, like is_idempotent or isLWT.
  • AttemptInfo containing info about specific attempt, passed to decide_should_retry. It would contain info about a specific attempt, like consistency or query error.

Why? To better utilize type system, documenting that query-related fields can't change between attempts.

Metadata

Metadata

Assignees

No one assigned

    Labels

    API-breakingThis might introduce incompatible API changesAPI-stabilityPart of the effort to stabilize the APIarea/statement-executionenhancementNew feature or requestperformanceImproves performance of existing features

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions