Traefik retry middleware retries non-idempotent POST and PATCH requests

Traefik's retry middleware re-sends requests to an upstream after connection failures or matching HTTP status codes, governed by the attempts option. The middleware applies retries to every HTTP method, including POST and PATCH, and does not expose a built-in filter to restrict retries to idempotent methods such as GET, HEAD, OPTIONS, PUT, or DELETE. If an upstream receives a non-idempotent request but the response is lost, Traefik may resend it and create duplicate side effects unless the application deduplicates using idempotency keys.

This question assumes a current Traefik v2 or v3 release, because retry semantics can differ between major versions. Middleware chain order also affects which responses become eligible for retry.

Can Traefik skip retries for non-idempotent methods? Does the attempts count include the original request, and does that count differ by Traefik major version? What middleware chain order reduces duplicate non-idempotent requests while preserving retries for safe methods?