Skip to content

Conversation

@PDGGK
Copy link

@PDGGK PDGGK commented Jan 20, 2026

What changes are being proposed in this pull request?

This PR addresses issue #37198 by making the withBackOffSupplier() method public in RequestResponseIO, allowing users to configure bounded backoff to prevent infinite retry loops.

Problem

Users cannot configure bounded retries because the withBackOffSupplier() method has package-private visibility. This leads to:

  • Inability to set retry limits (e.g., FluentBackoff.DEFAULT.withMaxRetries(3))
  • Risk of infinite retry loops in production
  • No way to control retry behavior for different failure scenarios

Solution

Changed withBackOffSupplier() visibility from package-private to public:

// Before:
RequestResponseIO<RequestT, ResponseT> withBackOffSupplier(SerializableSupplier<BackOff> value)

// After:
public RequestResponseIO<RequestT, ResponseT> withBackOffSupplier(
    SerializableSupplier<BackOff> value)

This allows users to configure bounded retries:

RequestResponseIO.of(caller, coder)
  .withBackOffSupplier(() -> FluentBackoff.DEFAULT.withMaxRetries(3).backoff())

Testing

Added comprehensive integration test givenBoundedBackoff_thenRetriesStopAfterLimit() that:

  • Uses a serializable BoundedBackOff class with zero delays (no real sleeps)
  • Verifies with PAssert that responses are empty and exactly 1 failure is emitted
  • Verifies with metrics that call count = maxRetries + 1 (initial call + 3 retries)
  • Verifies with metrics that failure count = 1

Test results:

  • ./gradlew :sdks:java:io:rrio:check passes
  • ✅ All existing tests continue to pass
  • ✅ New test validates bounded retry behavior

Impact

  • User benefit: Users can now prevent infinite retry loops by configuring bounded backoff
  • Backward compatibility: No breaking changes; existing code continues to work
  • Production readiness: Enables safer retry configurations for production workloads

Fixes #37198
Related to #37176

…y configuration

Users need to configure bounded backoff to prevent infinite retry loops.
Making withBackOffSupplier public allows users to set
FluentBackoff.DEFAULT.withMaxRetries(n) and control retry behavior.

Changes:
- Changed withBackOffSupplier() visibility from package-private to public
- Added comprehensive integration test with zero-delay BoundedBackOff
- Test verifies: responses empty, 1 failure emitted, call count = maxRetries+1

The test uses a serializable BoundedBackOff class with assertions on both
PAssert (pipeline outputs) and Metrics (retry counts) to ensure bounded
retry behavior works correctly.

Fixes apache#37198
Related to apache#37176

Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
@gemini-code-assist
Copy link
Contributor

Summary of Changes

Hello @PDGGK, I'm Gemini Code Assist1! 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 addresses a critical limitation in RequestResponseIO by making the withBackOffSupplier() method publicly accessible. This modification enables users to implement bounded retry mechanisms, effectively preventing potential infinite retry loops in production environments and offering enhanced control over error handling. The update ensures safer and more predictable retry configurations without introducing any breaking changes to existing functionality.

Highlights

  • Method Visibility Change: The withBackOffSupplier() method in RequestResponseIO has been changed from package-private to public, allowing external configuration of backoff strategies.
  • Bounded Retry Configuration Enabled: This change empowers users to configure bounded retries, preventing infinite retry loops and providing granular control over retry behavior for various failure scenarios.
  • New Integration Test: A comprehensive integration test, givenBoundedBackoff_thenRetriesStopAfterLimit(), was added to validate the new bounded retry functionality, including verification of call and failure counts using metrics.

🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console.

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.

@github-actions
Copy link
Contributor

Assigning reviewers:

R: @Abacn for label java.

Note: If you would like to opt out of this review, comment assign to next reviewer.

Available commands:

  • stop reviewer notifications - opt out of the automated review tooling
  • remind me after tests pass - tag the comment author after tests pass
  • waiting on author - shift the attention set back to the author (any comment or push by the author will return the attention set to the reviewers)

The PR bot will only process comments in the main thread (not review comments).

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

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[Feature Request]: RequestResponseIO: Unable to configure retry Backoff parameters; defaults to unlimited retries

1 participant