Does HttpRequestRetry ensure idempotency for POST requests during transport failures?

Answer to the exact question

No. The HttpRequestRetry plugin in Ktor only decides whether to retry a request based on the configured retryIf lambda, maxRetries, and exception types. It has no built‑in knowledge of whether the server has already applied the side effect of a POST request. Therefore, a retry after a transport failure that occurs after the body has been sent can still trigger duplicate writes unless the application adds its own idempotency logic.

Likely explanation

• The plugin retries blindly – it does not inspect the response status or the request method’s semantics.
• Once the HTTP body is streamed to the server, Ktor has no way to know if the operation succeeded on the server side.
• To prevent duplicate side effects you must add a stable Idempotency-Key header and rely on server‑side deduplication.
• In the client you can also prevent retries for POST after the body is sent by configuring retryIf to return false for that method or by disabling retryOnException for POST.

Confirmed facts (current Ktor 2.x)

1. The plugin’s API includes retryIf (lambda that receives HttpRequestData and Throwable) and maxRetries.
2. There is no flag that automatically marks POST as non‑retryable after the body has been sent.
3. Idempotency headers must be supplied by the developer; the plugin does not generate them.

Practical steps to prevent duplicate writes

1. Add an Idempotency key
   modifyRequest { request -> request.headers["Idempotency-Key"] = UUID.randomUUID().toString() }
2. 
   Set retryIf to exclude POST after the body is dispatched:

   install(HttpRequestRetry) {
       maxRetries = 3
       retryIf { request, throwable ->
           // Do not retry POST if the body has already been sent
           request.method.value.uppercase() != "POST" || throwable !is IOException
       }
   }

3. 
   The server must store the idempotency key and return the same result for repeated requests with that key.
4. 
   Use a proxy or mock server to drop the connection after the request body is streamed and verify that only one resource is created.

Missing diagnostic detail that could change the recommendation

Does the request body use a repeatable data source (e.g., ByteArrayContent) or a non‑repeatable stream (e.g., InputStreamContent)? If the body is non‑repeatable, a retry will fail with an exception rather than silently duplicate the write, and the strategy might need to change.