You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@iggy.apache.org by "ryankert01 (via GitHub)" <gi...@apache.org> on 2026/09/15 08:27:49 UTC
[PR] fix(connectors): honor Retry-After on every retried status [iggy]
ryankert01 opened a new pull request, #4192:
URL: https://github.com/apache/iggy/pull/4192
## Which issue does this PR address?
Closes #4168
## Rationale
`HttpRetryMiddleware` read `Retry-After` only on 429, but it retries any 5xx too.
## What changed?
The middleware now reads `Retry-After` on every status it already retries, so a
503 is no longer retried with the server's own timing thrown away. InfluxDB OSS
v2 documents the header on 503 and does not list 429, so the connector this
middleware was written for hit that directly; InfluxDB Cloud uses 429, which is
what the original code covered.
A new `MAX_RETRY_AFTER` bounds the honored value at 6 hours, matching urllib3's
`retry_after_max`. `max_delay` deliberately does not bound it, because a server
asking for longer than we would have chosen is the case the header exists for.
The bound guards against an absurd value, not against a stall: a connector
asleep for hours needs an alert, not a smaller constant. Happy to take a
different number.
**Follow-up:** [`parse_retry_after`](https://github.com/apache/iggy/blob/90615962cbf058959c52bada7931411c328272e0/core/connectors/sdk/src/retry.rs#L173)
accepts only the integer-seconds form, so the HTTP-date form that
[RFC 9110 §10.2.3](https://www.rfc-editor.org/rfc/rfc9110.html#name-retry-after)
also allows returns `None` and falls back to the computed backoff. Adding it
needs an `httpdate` or `chrono` dependency, so it stays a separate PR. Tracked in
#4168.
## Local Execution
- Passed — `fmt`, `clippy -D warnings` on the SDK and the three connectors using
`build_retry_client`, 174 SDK tests, `cargo doc` under `RUSTDOCFLAGS=-D warnings`.
- Both regression tests confirmed failing against the old behaviour first. The
other two new tests pin the bound's edges and pass either way; they guard a
future value change rather than this one.
- `prek` ran and passes, except `markdownlint`, `license-headers`,
`trailing-whitespace`, `trailing-newline` and `binary-artifacts`, which need
bash >= 4.2; ran those directly instead.
## AI Usage
- Claude Code.
- Implementation, tests and docs.
- Local chain above; prior art checked against urllib3, OTLP, AWS SDK and the
InfluxDB docs.
- Yes.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@iggy.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] fix(connectors): honor Retry-After on every retried status [iggy]
Posted by "codecov[bot] (via GitHub)" <gi...@apache.org>.
codecov[bot] commented on PR #4192:
URL: https://github.com/apache/iggy/pull/4192#issuecomment-5677778273
## [Codecov](https://app.codecov.io/gh/apache/iggy/pull/4192?dropdown=coverage&src=pr&el=h1&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache) Report
:white_check_mark: All modified and coverable lines are covered by tests.
:white_check_mark: Project coverage is 63.08%. Comparing base ([`9061596`](https://app.codecov.io/gh/apache/iggy/commit/90615962cbf058959c52bada7931411c328272e0?dropdown=coverage&el=desc&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache)) to head ([`92e136d`](https://app.codecov.io/gh/apache/iggy/commit/92e136de770947a0233413768847c5c496a24cd5?dropdown=coverage&el=desc&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache)).
<details><summary>Additional details and impacted files</summary>
```diff
@@ Coverage Diff @@
## master #4192 +/- ##
=============================================
- Coverage 87.42% 63.08% -24.35%
Complexity 1575 1575
=============================================
Files 1280 1278 -2
Lines 222704 183477 -39227
Branches 186067 146840 -39227
=============================================
- Hits 194706 115739 -78967
- Misses 23287 63140 +39853
+ Partials 4711 4598 -113
```
| [Components](https://app.codecov.io/gh/apache/iggy/pull/4192/components?src=pr&el=components&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache) | Coverage Δ | |
|---|---|---|
| [Rust Core](https://app.codecov.io/gh/apache/iggy/pull/4192/components?src=pr&el=component&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache) | `57.83% <100.00%> (-30.67%)` | :arrow_down: |
| [Java SDK](https://app.codecov.io/gh/apache/iggy/pull/4192/components?src=pr&el=component&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache) | `68.68% <ø> (ø)` | |
| [C# SDK](https://app.codecov.io/gh/apache/iggy/pull/4192/components?src=pr&el=component&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache) | `77.42% <ø> (ø)` | |
| [Python SDK](https://app.codecov.io/gh/apache/iggy/pull/4192/components?src=pr&el=component&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache) | `90.97% <ø> (ø)` | |
| [PHP SDK](https://app.codecov.io/gh/apache/iggy/pull/4192/components?src=pr&el=component&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache) | `85.67% <ø> (ø)` | |
| [Node SDK](https://app.codecov.io/gh/apache/iggy/pull/4192/components?src=pr&el=component&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache) | `96.43% <ø> (ø)` | |
| [Go SDK](https://app.codecov.io/gh/apache/iggy/pull/4192/components?src=pr&el=component&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache) | `70.08% <ø> (ø)` | |
| [Files with missing lines](https://app.codecov.io/gh/apache/iggy/pull/4192?dropdown=coverage&src=pr&el=tree&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache) | Coverage Δ | |
|---|---|---|
| [core/connectors/sdk/src/retry.rs](https://app.codecov.io/gh/apache/iggy/pull/4192?src=pr&el=tree&filepath=core%2Fconnectors%2Fsdk%2Fsrc%2Fretry.rs&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache#diff-Y29yZS9jb25uZWN0b3JzL3Nkay9zcmMvcmV0cnkucnM=) | `85.37% <100.00%> (-10.81%)` | :arrow_down: |
... and [517 files with indirect coverage changes](https://app.codecov.io/gh/apache/iggy/pull/4192/indirect-changes?src=pr&el=tree-more&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache)
</details>
<details><summary> :rocket: New features to boost your workflow: </summary>
- :snowflake: [Test Analytics](https://docs.codecov.com/docs/test-analytics): Detect flaky tests, report on failures, and find test suite problems.
- :package: [JS Bundle Analysis](https://docs.codecov.com/docs/javascript-bundle-analysis): Save yourself from yourself by tracking and limiting bundle sizes in JS merges.
</details>
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@iggy.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] fix(connectors): honor Retry-After on every retried status [iggy]
Posted by "hubcio (via GitHub)" <gi...@apache.org>.
hubcio commented on code in PR #4192:
URL: https://github.com/apache/iggy/pull/4192#discussion_r4211649471
##########
core/connectors/sdk/src/retry.rs:
##########
@@ -420,29 +437,35 @@ impl Middleware for HttpRetryMiddleware {
return Ok(response);
}
- // Parse Retry-After on 429 before falling back to our own
- // calculated backoff.
- let retry_after = if status == reqwest::StatusCode::TOO_MANY_REQUESTS {
- response
- .headers()
- .get("Retry-After")
- .and_then(|value| value.to_str().ok())
- .and_then(parse_retry_after)
- } else {
- None
- };
-
attempts += 1;
if is_transient_status(status) && attempts < self.policy.max_attempts {
+ // The cap is the operator's `max_delay`, not a constant of
+ // our own: the retry settings are the time budget for one
+ // `consume` or `poll` call, so the server must not stretch
+ // it. The runtime's HTTP state client caps `Retry-After`
+ // at its `max_backoff` for the same reason.
+ let requested = requested_retry_after(response.headers());
+ let delay = requested.map_or_else(
+ || self.policy.backoff(attempts),
+ |requested| requested.min(self.policy.max_delay),
Review Comment:
warning: every `Retry-After` above the cap now lands exactly on `max_delay`, so instances throttled together retry in lockstep - the same clamp #4129 removed from `retry_backoff`. draw it from the jitter window instead, e.g. `retry_backoff(self.policy.max_delay, 1, self.policy.max_delay)`.
##########
core/connectors/sdk/src/retry.rs:
##########
@@ -816,11 +839,102 @@ mod tests {
);
}
+ fn retry_after_header(value: &str) -> HeaderMap {
+ let mut headers = HeaderMap::new();
+ headers.insert(RETRY_AFTER, value.parse().unwrap());
+ headers
+ }
+
+ #[test]
+ fn given_a_retry_after_should_read_the_full_requested_delay() {
+ // The middleware applies the cap, and logs the full value when it does.
+ assert_eq!(
+ requested_retry_after(&retry_after_header("86400")),
+ Some(Duration::from_secs(86400))
+ );
+ }
+
+ #[test]
+ fn given_an_unusable_retry_after_should_fall_back_to_the_computed_backoff() {
+ for (header, why) in [
+ // Honoring zero spends the whole attempt budget inside one round
+ // trip, which is the opposite of what the server asked for.
+ ("0", "a zero header must not remove the backoff"),
+ (
+ "Wed, 21 Oct 2026 07:28:00 GMT",
+ "the HTTP-date form is not parsed yet",
+ ),
+ (
+ "not-a-number",
+ "an unparsable header must not stop the retry",
+ ),
+ ] {
+ assert_eq!(
+ requested_retry_after(&retry_after_header(header)),
+ None,
+ "{why}"
+ );
+ }
+ }
+
+ #[tokio::test]
+ async fn given_a_retry_after_past_max_delay_should_wait_no_longer_than_max_delay() {
+ // Three seconds rather than an hour keeps a failing run short.
+ let server = mock_then_ok(429, &[("Retry-After", "3")]).await;
+ let max_delay = Duration::from_millis(100);
+ let client = retry_client(3, Duration::from_millis(10), max_delay);
+
+ let started = Instant::now();
+ let response = client.get(server.uri()).send().await.unwrap();
+ let elapsed = started.elapsed();
+
+ assert_eq!(response.status(), 200);
+ assert_eq!(
+ server.received_requests().await.unwrap().len(),
+ 2,
+ "expected exactly one retry"
+ );
+ assert!(
Review Comment:
nit: only an upper bound here, so a middleware that drops an over-cap header and uses the 10ms backoff still passes. add `assert!(elapsed >= max_delay.mul_f64(JITTER_LOW))`.
##########
core/connectors/sdk/src/retry.rs:
##########
@@ -420,29 +437,35 @@ impl Middleware for HttpRetryMiddleware {
return Ok(response);
}
- // Parse Retry-After on 429 before falling back to our own
- // calculated backoff.
- let retry_after = if status == reqwest::StatusCode::TOO_MANY_REQUESTS {
- response
- .headers()
- .get("Retry-After")
- .and_then(|value| value.to_str().ok())
- .and_then(parse_retry_after)
- } else {
- None
- };
-
attempts += 1;
if is_transient_status(status) && attempts < self.policy.max_attempts {
+ // The cap is the operator's `max_delay`, not a constant of
+ // our own: the retry settings are the time budget for one
+ // `consume` or `poll` call, so the server must not stretch
+ // it. The runtime's HTTP state client caps `Retry-After`
+ // at its `max_backoff` for the same reason.
+ let requested = requested_retry_after(response.headers());
+ let delay = requested.map_or_else(
+ || self.policy.backoff(attempts),
+ |requested| requested.min(self.policy.max_delay),
+ );
// Consume the error body for logging, then retry.
let body_text = response.text().await.unwrap_or_default();
- let delay = retry_after.unwrap_or_else(|| self.policy.backoff(attempts));
- warn!(
- "{} transient error {status} \
- (attempt {attempts}/{}): {body_text}. \
- Retrying in {delay:?}...",
- self.log_prefix, self.policy.max_attempts
- );
+ match requested.filter(|requested| *requested > delay) {
+ Some(requested) => warn!(
+ "{} transient error {status} \
+ (attempt {attempts}/{}): {body_text}. \
+ Retrying in {delay:?}, capped by max_delay \
Review Comment:
nit: operators set `retry_max_delay`, not `max_delay` - name the config key here, like the READMEs do.
##########
core/connectors/sdk/src/retry.rs:
##########
@@ -816,11 +839,102 @@ mod tests {
);
}
+ fn retry_after_header(value: &str) -> HeaderMap {
+ let mut headers = HeaderMap::new();
+ headers.insert(RETRY_AFTER, value.parse().unwrap());
+ headers
+ }
+
+ #[test]
+ fn given_a_retry_after_should_read_the_full_requested_delay() {
+ // The middleware applies the cap, and logs the full value when it does.
+ assert_eq!(
+ requested_retry_after(&retry_after_header("86400")),
+ Some(Duration::from_secs(86400))
+ );
+ }
+
+ #[test]
+ fn given_an_unusable_retry_after_should_fall_back_to_the_computed_backoff() {
+ for (header, why) in [
+ // Honoring zero spends the whole attempt budget inside one round
+ // trip, which is the opposite of what the server asked for.
+ ("0", "a zero header must not remove the backoff"),
+ (
+ "Wed, 21 Oct 2026 07:28:00 GMT",
+ "the HTTP-date form is not parsed yet",
+ ),
+ (
+ "not-a-number",
+ "an unparsable header must not stop the retry",
+ ),
+ ] {
+ assert_eq!(
+ requested_retry_after(&retry_after_header(header)),
+ None,
+ "{why}"
+ );
+ }
+ }
+
+ #[tokio::test]
+ async fn given_a_retry_after_past_max_delay_should_wait_no_longer_than_max_delay() {
+ // Three seconds rather than an hour keeps a failing run short.
+ let server = mock_then_ok(429, &[("Retry-After", "3")]).await;
+ let max_delay = Duration::from_millis(100);
+ let client = retry_client(3, Duration::from_millis(10), max_delay);
+
+ let started = Instant::now();
+ let response = client.get(server.uri()).send().await.unwrap();
+ let elapsed = started.elapsed();
+
+ assert_eq!(response.status(), 200);
+ assert_eq!(
+ server.received_requests().await.unwrap().len(),
+ 2,
+ "expected exactly one retry"
+ );
+ assert!(
+ elapsed < Duration::from_secs(1),
+ "honored the raw header instead of the {max_delay:?} ceiling: waited {elapsed:?}"
+ );
+ }
+
+ #[tokio::test]
+ async fn given_a_retry_after_on_a_503_should_take_precedence_over_the_computed_backoff() {
Review Comment:
simplification: this duplicates the 429 test below apart from the status, one message and two comments. fold both into one test that loops over `[429, 503]` - saves ~25 lines.
##########
core/connectors/sdk/src/retry.rs:
##########
@@ -168,8 +169,8 @@ pub fn exponential_backoff(base: Duration, attempt: u32, max_delay: Duration) ->
}
/// Parse a `Retry-After` header value (integer seconds).
-/// Returns `None` for HTTP-date values — callers should fall back to their
-/// own backoff strategy.
+/// Returns `None` for any value that is not integer seconds, including the
+/// HTTP-date form — callers should fall back to their own backoff strategy.
pub fn parse_retry_after(value: &str) -> Option<Duration> {
Review Comment:
nit: `parse_retry_after` still drops the HTTP-date form that #4168 asks for, and no other issue tracks it. open a follow-up before merging, or change `Closes #4168` to `Refs #4168`.
##########
core/connectors/sdk/src/retry.rs:
##########
@@ -420,29 +437,35 @@ impl Middleware for HttpRetryMiddleware {
return Ok(response);
}
- // Parse Retry-After on 429 before falling back to our own
- // calculated backoff.
- let retry_after = if status == reqwest::StatusCode::TOO_MANY_REQUESTS {
- response
- .headers()
- .get("Retry-After")
- .and_then(|value| value.to_str().ok())
- .and_then(parse_retry_after)
- } else {
- None
- };
-
attempts += 1;
if is_transient_status(status) && attempts < self.policy.max_attempts {
+ // The cap is the operator's `max_delay`, not a constant of
+ // our own: the retry settings are the time budget for one
+ // `consume` or `poll` call, so the server must not stretch
+ // it. The runtime's HTTP state client caps `Retry-After`
+ // at its `max_backoff` for the same reason.
+ let requested = requested_retry_after(response.headers());
+ let delay = requested.map_or_else(
+ || self.policy.backoff(attempts),
+ |requested| requested.min(self.policy.max_delay),
Review Comment:
critical: with the 5s default `max_delay`, a 429 whose `Retry-After` window outlasts ~10s now burns all 3 attempts and the sink drops the chunk, since offsets are already committed at poll. give `Retry-After` its own much larger ceiling, as #4168 proposed.
##########
core/connectors/sdk/src/retry.rs:
##########
@@ -839,7 +953,7 @@ mod tests {
// The header asks for 1s. Anything far past it means the middleware
// added its own backoff on top instead of honoring the header.
assert!(
- elapsed < Duration::from_millis(1500),
+ elapsed < Duration::from_millis(2500),
Review Comment:
nit: a 2500ms bound lets a doubled 2s wait pass for a 1s header. go back to the old 1500ms - it still leaves room for slow runners and catches that.
also at line 927.
##########
core/connectors/sdk/src/retry.rs:
##########
@@ -352,11 +353,27 @@ pub fn is_transient_status(status: reqwest::StatusCode) -> bool {
status == reqwest::StatusCode::TOO_MANY_REQUESTS || status.is_server_error()
}
+/// Read the delay a response's `Retry-After` header asks for, before any cap.
+///
+/// Returns `None` when the header is absent, unreadable, zero, or in the
+/// HTTP-date form that [`parse_retry_after`] does not accept. Zero counts as
+/// absent because a server that answers "retry immediately" would otherwise
+/// spend the whole attempt budget inside one round trip. Every one of those
+/// cases leaves the caller on its own computed backoff.
+fn requested_retry_after(headers: &HeaderMap) -> Option<Duration> {
+ headers
+ .get(RETRY_AFTER)
+ .and_then(|value| value.to_str().ok())
+ .and_then(parse_retry_after)
+ .filter(|delay| !delay.is_zero())
Review Comment:
simplification: once the header can only lengthen the backoff (see line 448), a zero header falls back to the computed backoff on its own, so this filter, its doc and the zero test row can go.
##########
core/connectors/sources/influxdb_source/README.md:
##########
@@ -105,14 +105,16 @@ verbose_logging = false
timeout = "10s" # per-request timeout
max_retries = 3 # total query attempts, including the first (network errors, 429/5xx)
retry_delay = "1s" # initial backoff
-retry_max_delay = "5s" # backoff cap
+retry_max_delay = "5s" # cap for backoff and Retry-After
max_open_retries = 10 # total open() health-check attempts, including the first
open_retry_max_delay = "60s" # backoff cap for open() retries
circuit_breaker_threshold = 5 # consecutive failures before circuit trips
circuit_breaker_cool_down = "30s" # cooldown before queries resume
```
-Attempt counts are clamped to at least one. Query retries use exponential backoff with jitter; integer-seconds `Retry-After` on HTTP 429 can override the delay cap. Other HTTP errors and malformed successful response bodies fail the poll. Startup retries failed authenticated `GET /health` requests. Invalid duration strings warn and fall back to `1s`, while zero durations are accepted. `batch_size = 0` is clamped to `1`. Without `initial_offset`, the cursor starts at `1970-01-01T00:00:00Z`.
+Attempt counts are clamped to at least one. Query retries use exponential backoff with jitter. Integer-seconds `Retry-After` on HTTP 429 or any 5xx replaces the calculated delay, bounded by `retry_max_delay`. Raise `retry_max_delay` for a rate-limited backend that asks for longer waits.
+
+HTTP errors other than 429 and 5xx, and malformed successful response bodies fail the poll. Startup retries failed authenticated `GET /health` requests. Invalid duration strings warn and fall back to `1s`, while zero durations are accepted. `batch_size = 0` is clamped to `1`. Without `initial_offset`, the cursor starts at `1970-01-01T00:00:00Z`.
Review Comment:
nit: this reads like 429 and 5xx never fail the poll, but they do after the last attempt (`v2.rs:620`, `v3.rs:141`). say that, and that other HTTP errors fail it right away.
##########
core/connectors/sdk/src/retry.rs:
##########
@@ -420,29 +437,35 @@ impl Middleware for HttpRetryMiddleware {
return Ok(response);
}
- // Parse Retry-After on 429 before falling back to our own
- // calculated backoff.
- let retry_after = if status == reqwest::StatusCode::TOO_MANY_REQUESTS {
- response
- .headers()
- .get("Retry-After")
- .and_then(|value| value.to_str().ok())
- .and_then(parse_retry_after)
- } else {
- None
- };
-
attempts += 1;
if is_transient_status(status) && attempts < self.policy.max_attempts {
+ // The cap is the operator's `max_delay`, not a constant of
+ // our own: the retry settings are the time budget for one
+ // `consume` or `poll` call, so the server must not stretch
+ // it. The runtime's HTTP state client caps `Retry-After`
+ // at its `max_backoff` for the same reason.
+ let requested = requested_retry_after(response.headers());
+ let delay = requested.map_or_else(
Review Comment:
warning: a 503 with `Retry-After: 1` now beats a longer computed backoff, so a multi-minute `retry_delay` drops to 1s per retry. use `requested.min(self.policy.max_delay).max(self.policy.backoff(attempts))` so the header can only stretch the wait, and update the docs that say it replaces the backoff.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@iggy.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] fix(connectors): honor Retry-After on every retried status [iggy]
Posted by "hubcio (via GitHub)" <gi...@apache.org>.
hubcio merged PR #4192:
URL: https://github.com/apache/iggy/pull/4192
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@iggy.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] fix(connectors): honor Retry-After on every retried status [iggy]
Posted by "ryankert01 (via GitHub)" <gi...@apache.org>.
ryankert01 commented on PR #4192:
URL: https://github.com/apache/iggy/pull/4192#issuecomment-6082320101
I just opened a PR on website repo. https://github.com/apache/iggy-website/pull/133
/ready
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@iggy.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] fix(connectors): honor Retry-After on every retried status [iggy]
Posted by "ryankert01 (via GitHub)" <gi...@apache.org>.
ryankert01 commented on PR #4192:
URL: https://github.com/apache/iggy/pull/4192#issuecomment-6041557281
cc @hubcio
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@iggy.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] fix(connectors): honor Retry-After on every retried status [iggy]
Posted by "ryankert01 (via GitHub)" <gi...@apache.org>.
ryankert01 commented on PR #4192:
URL: https://github.com/apache/iggy/pull/4192#issuecomment-5992178441
@justinmclean Thanks you! I just finished the PR!!!
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@iggy.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] fix(connectors): honor Retry-After on every retried status [iggy]
Posted by "ryankert01 (via GitHub)" <gi...@apache.org>.
ryankert01 commented on PR #4192:
URL: https://github.com/apache/iggy/pull/4192#issuecomment-6057842321
Thanks for the review.
> nit: the website docs (`sinks/influxdb.mdx`, `sources/influxdb.mdx`, `sinks/quickwit.mdx` in apache/iggy-website) still say only a 429 `Retry-After` counts and that it overrides `retry_max_delay`. they need an update when this ships.
I'll open another pr at website repo.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@iggy.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] fix(connectors): honor Retry-After on every retried status [iggy]
Posted by "justinmclean (via GitHub)" <gi...@apache.org>.
justinmclean commented on PR #4192:
URL: https://github.com/apache/iggy/pull/4192#issuecomment-5880922941
Hi @ryankert01, this is still marked as a draft, so it won't show up for reviewers. CI is green. If it's ready, can you mark it ready for review? If you're still working on it, no rush.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@iggy.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org