We have encountered a persistent issue with the genesyscloud_interaction_participant_attributes resource in our CX-as-Code pipeline. The setup involves a voice call where an external system pushes custom attributes via the Conversations API. The Terraform configuration defines these attributes statically to ensure a baseline state.
The problem manifests during terraform plan. Even when the API returns the exact JSON payload defined in the HCL file, Terraform detects a drift and proposes an update. The API call to PUT /api/v2/conversations/voice/{conversationId}/participants/{participantId} succeeds with a 200 OK, but the state file seems to interpret the nested object structure differently than the provider expects.
Here is the relevant HCL snippet:
resource "genesyscloud_interaction_participant_attributes" "voice_call_attrs" {
conversation_id = genesyscloud_routing_queue.my_queue.id
participant_id = "external_system_id"
attributes = {
"custom.order_id" = "12345"
"custom.priority" = "high"
}
}
The API response payload looks like this:
{
"custom.order_id": "12345",
"custom.priority": "high"
}
The Terraform plan output shows:
# genesyscloud_interaction_participant_attributes.voice_call_attrs will be updated in-place
~ resource "genesyscloud_interaction_participant_attributes" "voice_call_attrs" {
~ attributes = {
- "custom.order_id" = "12345" -> null
- "custom.priority" = "high" -> null
}
}
This behavior suggests that the provider is not correctly parsing the response or is expecting a different schema for the attributes map. We have verified that the attribute keys match exactly, including the dot notation. The issue persists across multiple environments and does not appear to be related to specific conversation states.
Has anyone else observed this drift pattern with participant attributes? We are currently working around it by adding lifecycle { ignore_changes = [attributes] }, but this defeats the purpose of managing these values through code. The underlying mechanism for attribute synchronization in the Terraform provider seems to have a gap in handling dynamic or external-driven updates. We need a reliable way to lock these attributes in state without manual intervention.