1Add per-attempt timeout and idempotency-aware retries to the REST client - #161
1Add per-attempt timeout and idempotency-aware retries to the REST client#161ximpanz wants to merge 1 commit into
Conversation
|
Warning Review limit reached
More reviews will be available in 50 minutes and 21 seconds. Learn how PR review limits work. Your organization has run out of usage credits. Purchase more in the billing tab. ⌛ How to resolve this issue?After more reviews become available, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans include higher PR review limits than trial, open-source, and free plans. In all cases, reviews become available again over time. During sustained high-volume PR review activity, CodeRabbit may temporarily slow when the next review becomes available. Please see our Fair Usage Limits Policy for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (6)
📝 WalkthroughWalkthroughThis PR adds configurable HTTP retry logic with per-attempt timeouts to the Terraform NetBird provider. It implements a custom ChangesHTTP Retry and Configuration
Estimated code review effort🎯 4 (Complex) | ⏱️ ~60 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)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 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 `@internal/provider/provider.go`:
- Around line 83-98: intSetting currently accepts 0 and that 0 is passed through
as perTryTimeout into newRetryingHTTPClient causing immediate per-attempt
timeouts and possible retry storms; update intSetting (or the caller that reads
request_timeout) to treat 0 as invalid/default by enforcing request_timeout >= 1
(or mapping 0 -> def) so perTryTimeout is never 0, and add unit tests covering
perTryTimeout==0 behaviour and interaction with max_retries and idempotent
methods to verify retries/backoff; reference intSetting, request_timeout,
perTryTimeout, newRetryingHTTPClient and max_retries when making the change and
in test names.
🪄 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: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 2e29b5b0-28a4-4d7a-9b6e-c92b73a69a85
📒 Files selected for processing (6)
docs/index.mdinternal/provider/httpclient.gointernal/provider/httpclient_test.gointernal/provider/provider.gointernal/provider/provider_test.gointernal/provider/settings_test.go
The upstream SDK uses http.DefaultClient (no timeout) and a single Do() with no retries, so a stalled NetBird management API hangs plan/apply indefinitely, and transient 429/5xx/connection errors fail the whole run. The SDK also leaks the response body on its error path, which can wedge the connection pool after a burst of error responses. - internal/provider/httpclient.go: retryTransport, an http.RoundTripper with a per-attempt context timeout and bounded exponential backoff. 429 retries any method; 5xx and transport/timeout errors retry only idempotent methods (GET/HEAD/PUT/DELETE/OPTIONS) to avoid duplicate POST/PATCH side effects. Drains+closes bodies between attempts, honors Retry-After, and stops on outer context cancellation. - internal/provider/provider.go: pass the client via WithHttpClient(); new optional request_timeout (NB_REQUEST_TIMEOUT, default 30s) and max_retries (NB_MAX_RETRIES, default 4) provider settings. - internal/provider/httpclient_test.go: retry-policy unit tests. - internal/provider/settings_test.go: intSetting precedence tests (config > env > default, negative/invalid fallback). - internal/provider/provider_test.go: include the two new attributes in TestProviderUserAgent's config so it matches the updated schema. - docs/index.md: document request_timeout and max_retries.
b2db970 to
b63ac63
Compare
The upstream SDK uses http.DefaultClient (no timeout) and a single Do() with no retries, so a stalled NetBird management API hangs plan/apply indefinitely, and transient 429/5xx/connection errors fail the whole run. The SDK also leaks the response body on its error path, which can wedge the connection pool after a burst of error responses.
Summary by CodeRabbit
New Features
max_retriesconfiguration option to control Management API retry behavior (default: 4, configurable viaNB_MAX_RETRIES)request_timeoutconfiguration option to set per-attempt request timeout in seconds (default: 30, configurable viaNB_REQUEST_TIMEOUT)Documentation