Traefik retry middleware ↔ backend service: handling 409 Conflict on retries

Goal

Determine how Traefik’s retry middleware should interact with a backend that returns a 409 Conflict response to indicate a duplicate write, so that retries on non‑idempotent requests do not cause unintended resource duplication or infinite retry loops.

The retry middleware currently forwards the original request unchanged and decides to retry based only on configured status‑code conditions. When the backend signals a conflict, Traefik may treat the 409 as retryable if it matches the condition, leading to repeated attempts and potential duplicate writes unless the backend deduplicates.

Questions

• Should Traefik automatically treat 409 Conflict as a non‑retryable response for idempotency‑aware retry?
• Can a configuration option be added to exclude specific status codes from retry attempts?
• How can users signal idempotency to Traefik when using non‑idempotent HTTP methods?