Problem
Retry logic is currently hardcoded to 429 (Too Many Requests). Real-world APIs also return intermittent 500, 502, 503, 504 errors that warrant a retry. There is also no way to set a timeout on individual requests or on the connector as a whole, so a slow API can hang a task indefinitely.
Proposed features
1. Configurable retry status codes
Allow callers to declare which status codes trigger a retry:
ApiBuilder::new(url)
.retry_on(vec![429, 500, 502, 503, 504])
.max_retries(3)
.build()
Per-request override:
api.get("/resource")?
.retry_on(vec![503])
.await?
2. Per-request and per-connector timeouts
// Connector-level default
ApiBuilder::new(url)
.timeout(Duration::from_secs(30))
.build()
// Per-request override
api.get("/slow-endpoint")?
.timeout(Duration::from_secs(120))
.await?
Implemented via reqwest::ClientBuilder::timeout and reqwest::RequestBuilder::timeout, which are already available but not exposed.
Notes
- Timeout errors should surface as a dedicated
ApiError::Timeout variant rather than a generic ReqwestExecute error.
- Retry configuration should compose with the exponential backoff feature.
Problem
Retry logic is currently hardcoded to 429 (Too Many Requests). Real-world APIs also return intermittent 500, 502, 503, 504 errors that warrant a retry. There is also no way to set a timeout on individual requests or on the connector as a whole, so a slow API can hang a task indefinitely.
Proposed features
1. Configurable retry status codes
Allow callers to declare which status codes trigger a retry:
Per-request override:
2. Per-request and per-connector timeouts
Implemented via
reqwest::ClientBuilder::timeoutandreqwest::RequestBuilder::timeout, which are already available but not exposed.Notes
ApiError::Timeoutvariant rather than a genericReqwestExecuteerror.