fix: reduced the number of retries

[egordidenko]

Description

Checklist

• Tests (if applicable)
• Documentation (if applicable)
• Changelog stub (or use conventional commit messages)

Summary by CodeRabbit

• Chores
  • Updated the maximum retry limit for throttled requests, reducing it from 10 to 3 attempts.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[coderabbitai]

Walkthrough

A single configuration value in the initial config object was reduced from 10 to 3 for the retryThrottledRequestMaxTimes property, affecting retry behavior for throttled requests.

Changes

Cohort / File(s)	Summary
Configuration value update src/blocks/Config/initialConfig.ts	Changed retryThrottledRequestMaxTimes from 10 to 3 in the initialConfig object

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~2 minutes

Pre-merge checks and finishing touches

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Description check	⚠️ Warning	The PR description is entirely empty—only the template structure remains with no actual content, linked issue, or implementation details provided.	Fill in the description section with details about why retries were reduced, any related issue link, and check applicable checklist items. Consider using conventional commit format as suggested in the template.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title accurately describes the main change: reducing retry attempts for throttled requests from 10 to 3 in initialConfig.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch fix/update-retry-polling-logic

Warning

Review ran into problems

🔥 Problems

Errors were encountered while retrieving linked issues.

Errors (1)

• JIRA integration encountered authorization issues. Please disconnect and reconnect the integration in the CodeRabbit UI.

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 1

📜 Review details

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Disabled knowledge base sources:

• Jira integration is disabled by default for public repositories

You can enable these sources in your CodeRabbit configuration.

📥 Commits

Reviewing files that changed from the base of the PR and between c52ec43 and 10aa4cc.

📒 Files selected for processing (1)

• src/blocks/Config/initialConfig.ts

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)

• GitHub Check: build

[coderabbitai]

⚠️ Potential issue | 🟡 Minor

🧩 Analysis chain

🏁 Script executed:

# First, let's confirm the actual content of the file and surrounding context
cat -n src/blocks/Config/initialConfig.ts | head -60

Repository: uploadcare/file-uploader

Length of output: 2229

---

🏁 Script executed:

# Search for any references to retryThrottledRequestMaxTimes in the codebase
rg "retryThrottledRequestMaxTimes" -n -B 2 -A 2

Repository: uploadcare/file-uploader

Length of output: 1593

---

🏁 Script executed:

# Look for any related issues or discussions in the codebase
rg "retry.*throttle" -i -n
rg "throttle.*retry" -i -n

Repository: uploadcare/file-uploader

Length of output: 850

---

🏁 Script executed:

# Check if there are any tests related to this configuration
fd "\.test\.|\.spec\." -t f | xargs rg -l "retryThrottledRequestMaxTimes" 2>/dev/null || echo "No test files found"

Repository: uploadcare/file-uploader

Length of output: 87

---

🌐 Web query:

Uploadcare API rate limiting retry policies best practices

💡 Result:

Here are concise best-practice recommendations for handling Uploadcare API rate limiting and retries.

Key Uploadcare-specific items

• Honor 429 responses and any Retry-After header returned by Uploadcare. [1]
• Use Uploadcare’s multipart-upload options to control retries: set retryNetworkErrorMaxTimes and retryThrottledRequestMaxTimes when calling multipartStart. [2]
• Limit maxConcurrentRequests and choose an appropriate multipartChunkSize to reduce throttle risk. [2]

Retry strategy (recommended)

• On 429 or transient 5xx: stop immediate retries, then use exponential backoff with jitter (e.g., base 500–1000 ms, double each try, add random +/- up to 100–500 ms). Cap max delay (e.g., 30s–60s) and total retries (e.g., 3–8 attempts). [3]
• If Retry-After is present, delay at least that long before the next attempt (override exponential backoff for that request). [1][3]
• Only retry idempotent operations (GET, HEAD, PUT with idempotency keys); avoid blind retries for non-idempotent requests unless you implement server-side idempotency keys. [3]

Client design and operational practices

• Throttle outgoing concurrency at the client (global rate limiter) so aggregate calls stay under expected limits. [2][3]
• Prefer webhooks or server-side events instead of polling to reduce request volume. [2]
• Cache stable responses and batch requests where the API supports it. [3]
• Instrument logging & metrics (request counts, 429 rates, Retry-After values) and surface requestId/response details when contacting Uploadcare support. [1][3]
• Gracefully surface upload progress and retry states to users (cancel/abort options for long uploads). [2]

Implementation checklist (short)

• Read and respect Uploadcare 429/Retry-After behavior. [1]
• Configure multipartStart retry options and concurrency. [2]
• Implement exponential backoff + jitter, cap retries, obey Retry-After. [1][3]
• Use idempotency or avoid retrying unsafe operations. [3]
• Add metrics, logging, and fallbacks (webhooks, caching). [2][3]

Sources

• Uploadcare API reference (Upload API — 429/throttling notes). [1]
• Uploadcare blog: multipart uploads, retryNetworkErrorMaxTimes and retryThrottledRequestMaxTimes, concurrency controls. [2]
• General retry/backoff and rate-limit best practices (exponential backoff + jitter, honoring Retry-After, idempotency). [3]

---

Ensure the changelog and PR description document this revert from the previous 10-retry limit.

The value of 3 retries aligns with best practices for handling throttled requests (recommended range is 3–8 per Uploadcare and industry standards). This appears to be reverting the increase to 10 from issue #800, which confirms this is an intentional adjustment based on operational experience rather than an arbitrary change. The consistency with retryNetworkErrorMaxTimes: 3 is appropriate.

Verify that the CHANGELOG entry is updated to document this revert (e.g., referencing the prior increase from #800) and that the PR description explains the rationale.

🤖 Prompt for AI Agents

In src/blocks/Config/initialConfig.ts around line 49, the
retryThrottledRequestMaxTimes value was reverted to 3 from the previous 10;
update the CHANGELOG and the PR description to document this revert, explicitly
reference the prior increase from issue #800, and explain the operational
rationale (aligning with Uploadcare/industry guidance and consistency with
retryNetworkErrorMaxTimes: 3); ensure the PR description and changelog entry
mention the change, the issue number, and the reasoning for lowering retries to
3.