Can Envoy prevent duplicate writes when retrying non-idempotent HTTP requests?

Direct answer

No. Envoy does not natively prevent duplicate writes when it retries non-idempotent methods such as POST, PUT, or PATCH. Its retry mechanism is driven by status codes and network events, not by awareness of whether the upstream has already committed a side effect.

Confirmed behavior vs. likely explanation

Confirmed: Envoy retry policies evaluate conditions like retry_on: 5xx, connection resets, or connect failures. They do not inspect request bodies, generate idempotency tokens, or maintain a deduplication table. There is no built-in filter that tracks in-flight request hashes to suppress duplicate attempts.

Likely explanation: When an upstream processes a write but the response is lost, or when a 5xx is returned after the write commits, Envoy sees only a retry-eligible failure. It will replay the identical request. The proxy cannot distinguish a request that failed before the write from one that failed after the write succeeded.

Steps to prevent duplicate writes

1. Disable retries for non-idempotent routes. If the upstream cannot deduplicate, do not configure retry_on for routes handling POST, PUT, or PATCH. A route-level retry policy that omits these methods is the safest default.
2. Delegate idempotency to the upstream. Have clients send a unique idempotency key (for example, an Idempotency-Key header). The upstream service stores the key and returns the original response for duplicate submissions. Envoy can pass the header through without modification.
3. Use an external filter only if necessary. A Lua or WASM filter can track request fingerprints, but this adds memory and latency overhead. Any in-flight table must be bounded and evicted after the request stream completes.

Interaction with retry budgets and timeouts

A custom idempotency filter would need to coordinate with Envoy's retry budget so that suppressed retries do not consume budget intended for legitimate failures. Per-try timeouts (per_try_timeout) still apply independently; if the first attempt exceeds the timeout but the upstream continues processing, a retry can race with the original request. In-flight tracking must therefore survive the interval between attempts while being cleaned up when the stream ends.

Verification

To confirm the risk, configure a test route with retry_on: 5xx and point it to a mock upstream that logs each request and returns 503 after writing. If the response is lost or a 5xx is returned, Envoy will issue a second request, producing a duplicate log entry. Review your production configuration to ensure non-idempotent methods are excluded from retry policies unless the upstream enforces idempotency.

One diagnostic question

Can your upstream service accept and enforce an idempotency key? If yes, retries can remain enabled because the application layer will absorb duplicates. If no, the recommendation is to disable retries for non-idempotent methods at the Envoy route level.