Skip to content

[Feature]: Implement Automatic Request Retry Mechanism #2

@dinocodesx

Description

@dinocodesx

Describe the Feature You Are Requesting

Currently, Termino-Logistic sends HTTP requests without retrying if a request fails due to network issues, timeouts, or server errors. In scenarios where APIs may experience temporary downtime or intermittent issues, automatic request retries would improve the tool’s reliability and performance.

💡 Proposed Feature:

  • Implement a configurable retry mechanism that automatically resends failed requests.
  • Allow users to define:
    • Maximum number of retries
    • Retry delay (in seconds) between attempts
    • List of HTTP status codes that trigger a retry (e.g., 500, 503)
    • Timeout-based retries for connection issues

📝 Example Usage:

# Retry a request up to 3 times with a 5-second delay
termino -f request.yml --retries 3 --retry-delay 5

Why Is This Feature Needed?

  • Reliability: Improves API request success rates for unstable or overloaded servers.
  • Automation: Eliminates the need for users to manually retry requests.
  • User Experience: Provides a seamless experience without requiring intervention.

How to Implement

1️⃣ Argument Parsing Update

  • Add CLI options for:
    • Maximum retry count
    • Retry delay
    • List of status codes to trigger retries
    • Optional exponential backoff (gradually increasing delay)

2️⃣ Retry Logic Implementation

  • Wrap the request execution in a retry loop.
  • Resend the request if the response matches a retryable status code or if a network issue occurs.
  • Wait for the specified delay between retries.

3️⃣ Graceful Exit Condition

  • Terminate retries after reaching the maximum attempt count.
  • Log appropriate messages indicating the number of retries and final status.

4️⃣ Configurable Backoff Strategy

  • Allow optional exponential backoff where each retry delay is doubled to reduce server load.

5️⃣ Testing and Error Handling

  • Write unit tests to validate retry behavior under different scenarios.
  • Handle exceptions gracefully and provide clear error messages.

6️⃣ Documentation and Examples

  • Update the README with examples of how to configure retries.
  • Provide best practices for selecting retry settings.

Additional Context

  • This feature would align with standard HTTP client libraries like requests and curl.
  • Retry configurations should prioritize API efficiency without overwhelming the server.
  • Potential future enhancement: Add retry logging to separate log files.

Would love to hear thoughts from the community! Feel free to take this issue up! 🚀

Metadata

Metadata

Assignees

No one assigned

    Labels

    apertre2.0Issues and PRs created during Apertre EventenhancementNew feature or requestmediumA difficulty tag

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions