vCenter Server API and External Automation Client: safe retry for mutating writes without duplicates

An external automation client needs to issue mutating vSphere operations such as CreateVM_Task, ReconfigureVM_Task and CreateDisk_Task against vCenter Server API and be able to retry on transient transport failures without creating duplicate VMs, disks or configuration changes.

vSphere exposes mutating operations as asynchronous Tasks tied to a Managed Object Reference. The client receives a task identifier and polls for completion. The API does not document a client-supplied idempotency key for these writes, and exactly-once semantics are not guaranteed across network partitions or vCenter failover. Behavior is version-sensitive and depends on the specific object manager implementation.

Client-side deduplication is commonly discussed via querying recentTasks on the target object and filtering by operation type, arguments and start time to decide whether to reuse an existing task. The trade-off between operation latency and risk of duplicate writes remains unresolved, particularly the window to poll a potentially orphaned task before treating it as failed.

What criteria are reliable for matching an in-flight or recently completed task to a retry attempt? How should the polling window for an orphaned task be bounded before a retry is considered safe? Are there documented guarantees for task uniqueness per object manager implementation?