impl(v3): add attempt predicate to AsyncRetryLoop

[scotthart]

Adds support for an optional predicate for determining when to end the retry loop.

[gemini-code-assist]

Summary of Changes

Hello @scotthart, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request significantly enhances the AsyncRetryLoop by introducing an optional attempt_predicate. This predicate empowers developers with greater control over the retry mechanism, enabling them to define specific conditions under which a retry loop should terminate, even if an individual operation succeeds. This added flexibility allows for more sophisticated and application-specific retry strategies, moving beyond simple success/failure checks.

Highlights

• Enhanced Retry Loop Control: Introduced an optional attempt_predicate to the AsyncRetryLoopImpl class and the AsyncRetryLoop free function, allowing for custom logic to determine when a successful operation should terminate the retry loop.
• Conditional Loop Termination: The OnAttempt method now utilizes the attempt_predicate to provide more granular control over when the asynchronous retry loop concludes, even if an operation initially returns a successful status.
• New Test Coverage: Added a new test case, TransientPredicateThenSuccess, to validate the correct behavior of the attempt_predicate in scenarios where the loop continues despite initial successful attempts.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request introduces an optional predicate to the AsyncRetryLoop to provide more fine-grained control over when the retry loop should terminate, even on successful attempts. The implementation is sound and includes a corresponding test case to validate the new functionality. I have one suggestion to simplify the logic in OnAttempt for better readability and maintainability.

[devbww]

Why pass result when it is always OK? Or should result.ok() not be a precondition?

[scotthart]

I'm assuming you're asking why it's not
if (result.ok() && attempt_predicate(*result)) {

This was to avoid trying to deduce/handle whether T is Status or StatusOr<U>.

[devbww]

I'm unsure of what you're trying to achieve, but what I was (badly) attempting to say is that "retrying" a successful call sounds wrong ... at least within a retry loop like this. That seems like something best handled way up at the application layer, not by a client-library option. And its relationship to the retry policy is cloudy at best.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 92.87%. Comparing base (9429a07) to head (41b1a34).
⚠️ Report is 2 commits behind head on prepare-for-v3.0.0.

Additional details and impacted files

@@                 Coverage Diff                 @@
##           prepare-for-v3.0.0   #15915   +/-   ##
===================================================
  Coverage               92.87%   92.87%           
===================================================
  Files                    2343     2343           
  Lines                  216117   216153   +36     
===================================================
+ Hits                   200719   200757   +38     
+ Misses                  15398    15396    -2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.