Skip to content
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

RetryPolicy LWT support #1155

Open
Lorak-mmk opened this issue Dec 17, 2024 · 0 comments
Open

RetryPolicy LWT support #1155

Lorak-mmk opened this issue Dec 17, 2024 · 0 comments
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

Comments

@Lorak-mmk
Copy link
Collaborator

Lorak-mmk commented Dec 17, 2024

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.

@Lorak-mmk Lorak-mmk added enhancement New feature or request API-breaking This might introduce incompatible API changes performance Improves performance of existing features API-stability Part of the effort to stabilize the API area/statement-execution labels Dec 17, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
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
Projects
None yet
Development

No branches or pull requests

1 participant