Traefik retry middleware retries non-idempotent POST and PATCH requests

Traefik's retry middleware cannot natively skip retries for non-idempotent methods like POST or PATCH. It applies the retry logic to any request that matches the router's criteria and triggers a retry condition (such as a connection failure or a configured HTTP status code), regardless of the HTTP method used.

Attempt Counting and Versioning

In Traefik v2 and v3, the attempts parameter represents the total number of requests sent to the upstream, including the initial attempt. For example, setting attempts: 3 means Traefik will send the original request and up to two subsequent retries if the initial attempt fails.

Preventing Duplicate Non-Idempotent Requests

Since there is no built-in method filter, you must isolate the retry logic at the routing level to avoid duplicate side effects on your backend. The most effective strategy is to split your traffic into separate routers based on the HTTP method.

1. Create a "Safe" Router: Define a router that only matches idempotent methods (GET, HEAD, OPTIONS, PUT, DELETE). Attach the retry middleware to this router.
2. Create a "Non-Idempotent" Router: Define a separate router for POST and PATCH requests. Do not attach the retry middleware to this router.
3. Application-Level Deduplication: For POST and PATCH requests, rely on idempotency keys (e.g., Idempotency-Key header) implemented in the application logic to handle cases where a request is processed by the backend but the response is lost during transmission.

Middleware Chain Order

To minimize the overhead of retries, place the retry middleware as close to the service as possible in the chain. While this does not stop POST retries if the middleware is present, it ensures that previous middlewares (such as authentication or request transformation) are not unnecessarily re-executed for every retry attempt.

Verification Steps

To verify your configuration, you can use the following approach:

• Set attempts: 3 on a test route.
• Induce a connection failure at the upstream.
• Check your backend access logs; if you see three incoming requests for a single client call, the attempts count includes the original request.
• Confirm that POST requests to your isolated "non-idempotent" router result in only one attempt regardless of the failure.

Note: Please specify if you are using a custom Traefik plugin for retries, as plugins may implement different filtering logic than the core middleware.