fix(gax): adjust RetryAlgorithm logic for timeout v. exception#13243
fix(gax): adjust RetryAlgorithm logic for timeout v. exception#13243whowes wants to merge 5 commits into
Conversation
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request modifies the RetryAlgorithm to short-circuit the retry check when an operation succeeds and the result algorithm indicates no retry is necessary. This change prevents the timing algorithm from erroneously throwing a CancellationException on successful operations. New unit tests were added to verify both the short-circuiting behavior and the standard path. Feedback suggests adding a missing assertion to one of the new test cases to explicitly verify the return value of the retry decision.
whowes
force-pushed
the
whowes/issue-12373-flaky
branch
from
32b949e to
f648950
Compare
whowes
force-pushed
the
whowes/issue-12373-flaky
branch
from
3cff2d3 to
54b9310
Compare
|
/gemini review |
There was a problem hiding this comment.
Code Review
This pull request modifies the RetryAlgorithm.shouldRetry method to short-circuit when an operation has succeeded. Specifically, if the result-based retry check returns false and there is no previous exception, the method now returns false immediately without calling the timing-based retry check. This change prevents the timing-based check from erroneously throwing a CancellationException on successful operations. Corresponding unit tests were added to verify the short-circuiting behavior and ensure timing checks still occur when an error is present. I have no feedback to provide as there were no review comments to evaluate.
|
|
1 participant
The current RetryAlgorithm logic is susceptible to an edge case if a short RPC deadline is set near the end of polling. If an exception results from a too-short deadline, the exception thrown by the associated Future will be an ExecutionException rather than CancellationException. This likely causes flakiness observed in #12373 and #3277.
This change ensures that shouldRetryBasedOnTiming executes if the operation hasn't completed successfully, even when shouldRetryBasedOnResult is false (e.g. due to non-retriable RPC exception due to the short deadline). This way a CancellationException will be thrown instead if the overall timeout has been reached.
Resolves #12373