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

Only retry idempotent operations by default. Fixes #1444 #1445

Merged
merged 2 commits into from
Feb 18, 2025

Conversation

jcferretti
Copy link
Contributor

@jcferretti jcferretti commented Feb 16, 2025

See description on #1444

@jcferretti jcferretti changed the title Do not retry by default non-idempotent operations. Fixes #1444 Only retry non-idempotent operations by default. Fixes #1444 Feb 16, 2025
@jcferretti jcferretti changed the title Only retry non-idempotent operations by default. Fixes #1444 Only retry idempotent operations by default. Fixes #1444 Feb 16, 2025
@jcferretti
Copy link
Contributor Author

Note the PR is also renaming a test case,
public void testAuthErrorIsNotRetryable()
to
public void testAuthErrorIsRetryable()
in trying to correctly reflect what the test is actually doing (the test was, and still is, checking that the error is retryable)

@lburgazzoli
Copy link
Collaborator

@jcferretti thx a lot for the PR, wonder if the autoRetry flag could be added to the related *Option object, instead of an additional method argument.

@jcferretti
Copy link
Contributor Author

jcferretti commented Feb 17, 2025

@jcferretti thx a lot for the PR, wonder if the autoRetry flag could be added to the related *Option object, instead of an additional method argument.

You are welcome, thanks for the quick followup.

Good call on putting autoRetry behind Option objects, much better, less interface pollution. Done!

@jcferretti
Copy link
Contributor Author

I used the chance to add a few more javadoc comments to other options, eg,

    /**
     * Only populate results for keys that match a
     * minimum value for a created revision.
     *
     * Note this filter does not affect the Count field in GetResponse.
     * Count always counts the number of keys matched on a range, independent of other filters.
     *
     * @return minimum created revision to match, or zero for any.
     */
    public long getMinCreateRevision() {
        return this.minCreateRevision;
    }

The semantics of count not matching requested filters bit me in the past: etcd-io/etcd#18267
I am trying to help prevent it biting others in the future.

@jcferretti jcferretti force-pushed the cfs-nosaferedoretry branch 3 times, most recently from a0261e8 to 07ba51f Compare February 18, 2025 04:37
Also use the chance to improve javadoc on some *Options objects

Signed-off-by: Cristian Ferretti <jcferretti2020@gmail.com>
@k8s-ci-robot
Copy link

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: jcferretti, lburgazzoli

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@lburgazzoli lburgazzoli merged commit 08def01 into etcd-io:main Feb 18, 2025
8 of 9 checks passed
@jcferretti
Copy link
Contributor Author

@lburgazzoli thank you very much for the quick turnaround. Any chance there will be a new minor release including this in the medium term? My team would like to pick it up for our system once available. Not immediately urgent for us, but since it impacts reliability, it would be nice to have some understanding/visibility for when.

@lburgazzoli
Copy link
Collaborator

hope before of end of the week

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

Successfully merging this pull request may close these issues.

3 participants