feat: use retry interceptor for streaming calls #400
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
PR Description:
Overview:
This leverages the method.getType().clientSendsOneMessage() check, where:
Since both unary and server-side streaming calls return true for
clientSendsOneMessage()
, the existing interceptor logic is inherently compatible with server-side streaming calls. To enable retries forgetBatch
specifically, this PR simply adds it to the list of API calls that should trigger retries.Enhancements:
cancelAttempt
call to release resources if the client decides to stop retrying. This prevents the program from hanging by ensuring that any remaining resources are cleaned up.Testing
To verify the retry functionality for streaming calls, I:
getBatch
, retrying on failure. This allowed for validating that retries work as expected and that resources are released properly upon completion.This setup confirmed that RetryInterceptor effectively handles retries for both unary and streaming calls, ensuring robust error handling for getBatch requests.
Issue
#398