Does HttpRequestRetry ensure idempotency for POST requests during transport failures?

Handling Write Retries in Ktor Client

When using the HttpRequestRetry plugin in Ktor (JVM), the client can be configured to retry requests based on server errors or specific exceptions. However, a critical uncertainty arises when a timeout or connection reset occurs after the server has already processed a write operation but before the client receives the response.

In this scenario, the client perceives a failure and triggers a retry. If the endpoint is a POST request, this behavior can lead to duplicate resource creation or redundant side effects unless the server-side logic explicitly handles deduplication.

While PUT and DELETE are defined as idempotent, POST operations are not. There is no built-in mechanism within the Ktor client plugin to automatically coordinate with the server to ensure a retry does not result in a duplicate write.

• How should the modifyRequest block be utilized to maintain a consistent idempotency key across multiple retry attempts?
• Which specific configuration in HttpRequestRetry prevents the client from retrying a POST request when the failure occurs after the request body has been fully dispatched?