Does Traefik Mesh provide built‑in request deduplication for retries to avoid duplicate writes?

Question

Goal
Determine whether Traefik Mesh can be configured to prevent duplicate side‑effects when retrying requests that use non‑idempotent HTTP methods such as POST, PUT, or PATCH.
Constraints and uncertainty
Traefik Mesh relies on Traefik Proxy’s retry middleware, which retries based on attempt count and status codes but does not deduplicate requests. The mesh documentation advises using application‑level idempotency headers, yet there is an open discussion about adding built‑in idempotency support. It is unclear if a future release will provide request‑level deduplication or if users must continue to implement idempotency keys themselves.
Which approach should be taken to handle retries safely for non‑idempotent methods without relying on application‑level idempotency keys?

Tasadduq Burney · Answer

Short answer
No. Traefik Mesh does not provide built-in request deduplication for retries. It relies on Traefik Proxy’s retry middleware, which retries based on attempt count and matching status codes. The middleware does not generate idempotency keys, inspect request bodies, or prevent the backend from receiving the same state-changing request more than once.
Confirmed facts and likely explanation
Confirmed: Traefik Mesh delegates retry behavior to Traefik Proxy. The retry middleware has no idempotency-key generation or request-body deduplication for POST, PUT, or PATCH. Retry rules control how often a request is retried, not whether duplicate writes are prevented.
Likely: If a POST, PUT, or PATCH request reaches the backend but the response is lost, a mesh retry can cause the backend to process the same operation again, creating duplicate writes.
Uncertain: Whether a current or upcoming Traefik Mesh release adds mesh-level request deduplication. Treat any roadmap mention as unconfirmed until it appears in release documentation.
Recommended steps

Disable mesh retries for POST, PUT, and PATCH unless the backend explicitly guarantees idempotency through keys or tokens.
Implement idempotency at the application layer: clients send an Idempotency-Key header, and the backend stores and rejects repeated keys for the same state-changing operation.
Restrict mesh retries to safe methods such as GET, HEAD, and OPTIONS, or to methods your backend documents as idempotent.

Verification
Send a POST request, force a transient failure after the backend has processed it but before it responds, and allow Traefik Mesh to retry. Inspect backend logs or the data store to confirm whether the operation was executed more than once.
Assumptions
This assumes current Traefik Proxy retry middleware behavior. Future releases may change retry or deduplication support; verify against your installed version’s documentation.
Missing diagnostic detail
Does your backend already validate idempotency keys for state-changing endpoints? If yes, mesh retries may be acceptable for those endpoints. If no, keep retries disabled for POST, PUT, and PATCH at the mesh layer.

Does Traefik Mesh provide built‑in request deduplication for retries to avoid duplicate writes?

Goal

Constraints and uncertainty

1 answer

Short answer

Confirmed facts and likely explanation

Recommended steps

Verification

Assumptions

Missing diagnostic detail

Your perspective belongs here.

0 question comments