Which mechanism ensures write idempotency during API server retries?

When implementing custom controllers in Kubernetes (v1.28+), ensuring that retried write operations do not result in duplicate resources or overwritten data is critical. The API server utilizes optimistic concurrency control via the resourceVersion field to prevent conflicting updates during PUT requests.

While resourceVersion manages updates, the behavior for POST (create) operations relies on the uniqueness of the resource name within a namespace. However, in scenarios where a client receives a timeout or a network error after a write was successfully committed to etcd, a naive retry may result in a 409 Conflict if the resource already exists.

There is a design uncertainty regarding the most efficient way to handle these retries without introducing excessive GET requests to verify state before every attempt.

• Does Server-Side Apply provide a more robust idempotency guarantee for retries compared to standard PUT operations?
• What is the recommended pattern for distinguishing between a legitimate conflict and a retry of a previously successful but unacknowledged write?