Idempotency-Key header vs. etag/resourceVersion deduplication for Rancher API retries

Goal: configure Rancher API call retries so that transient failures do not cause duplicate resource creation or updates.

Constraints: the Idempotency-Key header is only honored in Rancher v2.6+ when the feature flag is enabled; older versions ignore it and may duplicate writes. Relying on etag/resourceVersion for deduplication assumes the underlying Kubernetes API increments the version on every change; if a controller skips a version bump, needed updates could be suppressed. Client‑side log‑based deduplication requires the retry library to persist its log across restarts, otherwise a crash can lose the log and cause missed retries.

Which approach provides the strongest guarantee against duplicate writes while remaining operable across the versions and failure scenarios typically encountered in production?

• Does enabling the Idempotency-Key feature flag prevent duplicate writes even when the client retries after a network partition?
• If the Kubernetes API does not increment resourceVersion on every change, how does etag‑based deduplication behave?
• What operational overhead is introduced by persisting a client‑side retry log compared with using the server‑side Idempotency-Key?