Update retryable errors and delay#1708
Conversation
The values are synced with `minio-go`. Signed-off-by: Bala.FA <[email protected]>
📝 WalkthroughWalkthrough
ChangesRetry configuration tuning
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
There was a problem hiding this comment.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
api/src/main/java/io/minio/Http.java (1)
744-757:⚠️ Potential issue | 🟠 Major | ⚡ Quick winUnify default retry delay across constructor paths.
Line 745 still defaults to
100, while Line 756 now falls back to200wheninterceptor == null. This creates inconsistent retry behavior depending on which constructor path is used (includingnewDefaultClient()vs chained constructor usage).Suggested fix
public StatusRetryInterceptor() { - this(RETRIABLE_STATUS_CODES, 100, 5, null, false); + this(RETRIABLE_STATUS_CODES, 200, 5, null, false); }🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@api/src/main/java/io/minio/Http.java` around lines 744 - 757, The StatusRetryInterceptor class has inconsistent default retry delay values across its constructors. The no-arg constructor on line 745 defaults to 100ms, while the three-parameter constructor on line 756 falls back to 200ms when interceptor is null. Unify these by changing the delayMs parameter in the no-arg StatusRetryInterceptor() constructor from 100 to 200 so all constructor paths use the same default delay value.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@api/src/main/java/io/minio/PutObjectBaseArgs.java`:
- Line 152: The Javadoc comment for the delay setting incorrectly states that a
value <= 0 disables retry, but the actual behavior is that delayMs <= 0 only
disables the backoff delay between retries, while the number of retries is
controlled by the maxRetries parameter. Update the Javadoc comment to correctly
describe that delayMs <= 0 disables the delay between retries (not the retries
themselves), and clarify that retry behavior is controlled by the maxRetries
parameter instead.
---
Outside diff comments:
In `@api/src/main/java/io/minio/Http.java`:
- Around line 744-757: The StatusRetryInterceptor class has inconsistent default
retry delay values across its constructors. The no-arg constructor on line 745
defaults to 100ms, while the three-parameter constructor on line 756 falls back
to 200ms when interceptor is null. Unify these by changing the delayMs parameter
in the no-arg StatusRetryInterceptor() constructor from 100 to 200 so all
constructor paths use the same default delay value.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: c2894d9b-985d-48b9-a5ee-cde9a7d09439
📒 Files selected for processing (6)
api/src/main/java/io/minio/BaseS3Client.javaapi/src/main/java/io/minio/CompleteMultipartUploadArgs.javaapi/src/main/java/io/minio/ComposeObjectArgs.javaapi/src/main/java/io/minio/Http.javaapi/src/main/java/io/minio/PutObjectBaseArgs.javaapi/src/main/java/io/minio/RemoveObjectsArgs.java
| } | ||
|
|
||
| /** Set delay between retries. Value <= 0 disables retry (default 100ms). */ | ||
| /** Set delay between retries. Value <= 0 disables retry (default 200ms). */ |
There was a problem hiding this comment.
Fix delayMs Javadoc behavior wording.
Line 152 says <= 0 disables retry, but delayMs <= 0 only disables backoff delay; retries are controlled by maxRetries.
Suggested fix
-/** Set delay between retries. Value <= 0 disables retry (default 200ms). */
+/** Set delay between retries. Value <= 0 makes no delay (default 200ms). */📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| /** Set delay between retries. Value <= 0 disables retry (default 200ms). */ | |
| /** Set delay between retries. Value <= 0 makes no delay (default 200ms). */ |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@api/src/main/java/io/minio/PutObjectBaseArgs.java` at line 152, The Javadoc
comment for the delay setting incorrectly states that a value <= 0 disables
retry, but the actual behavior is that delayMs <= 0 only disables the backoff
delay between retries, while the number of retries is controlled by the
maxRetries parameter. Update the Javadoc comment to correctly describe that
delayMs <= 0 disables the delay between retries (not the retries themselves),
and clarify that retry behavior is controlled by the maxRetries parameter
instead.
The values are synced with
minio-go.Summary by CodeRabbit