What is the standard approach to manage idempotency keys when updating participant attributes mid-conversation via the Conversations API to ensure Terraform state consistency without race conditions?
We are using the Genesys Cloud Conversations API to set custom participant attributes (specifically routing.queue.name overrides and custom custom_attributes) during active interactions. This is part of a larger CX-as-Code workflow where our CI/CD pipeline reconciles state. We use PATCH /api/v2/conversations/medias/{mediaId}/participants/{participantId} with the following payload:
{
"custom_attributes": {
"flow_version": "v2.1",
"priority": "high"
},
"routing": {
"queue": {
"name": "Priority-Support"
}
}
}
The issue arises when multiple parallel Terraform apply operations or retry logic trigger concurrent updates to the same participant. We are seeing intermittent 409 Conflict errors when the If-Match header (ETag) becomes stale due to another process updating the participant record simultaneously. The API requires the ETag for optimistic locking, but our Terraform provider does not automatically fetch the latest ETag before applying changes in parallel.
409 Conflict
{ "errors": [ "Resource version mismatch. The resource was modified by another process." ] }
Should we implement a client-side retry loop that fetches the latest resource state via GET before each PATCH to refresh the ETag? Or is there a recommended pattern for handling these concurrent attribute updates in a Terraform-managed environment where idempotency is critical? We want to avoid race conditions that cause state drift.
Also, does the API support partial updates without requiring the full resource representation in the body? We only want to update specific attributes to minimize the risk of overwriting other system-managed fields.