Skip to content

Feature: configurable retry on any HTTP status code + per-request timeouts #53

Description

@ZialeHub

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    B-ideaDiscussion; or implementation attempt, to be reviewed before further workrustPull requests that update rust code

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions