Could someone explain why my terraform plan keeps showing unnecessary drift on the genesyscloud_routing_queue resource even when no changes were made to the configuration files?
i am using the genesys cloud terraform provider version 1.32.0. my workflow involves running terraform plan followed by terraform apply to manage our WhatsApp integration routing queues. recently, every plan output indicates that the long_description and wrap_up_timeout fields are changing, despite these values matching the current state in the Genesys Cloud UI and the .tfstate file.
here is the relevant resource block:
resource "genesyscloud_routing_queue" "whatsapp_inbound" {
name = "WhatsApp Inbound Queue"
long_description = "Primary queue for WhatsApp HSM templates"
description = "Handles inbound WhatsApp messages"
wrap_up_timeout = 60000
email_enabled = false
acd_skill_required = false
members {
user_id = "550e8400-e29b-41d4-a716-446655440000"
}
}
when i run terraform plan, i see this output:
# genesyscloud_routing_queue.whatsapp_inbound will be updated in-place
~ resource "genesyscloud_routing_queue" "whatsapp_inbound" {
~ long_description = "Primary queue for WhatsApp HSM templates" -> (known after apply)
~ wrap_up_timeout = 60000 -> (known after apply)
}
i suspect this might be related to a state lock issue or how the provider handles read-backs from the /api/v2/routing/queues/{id} endpoint. i have tried running terraform refresh and manually editing the state file to remove the long_description attribute, but the drift persists.
is there a known bug in the provider where it fails to reconcile the long_description field correctly? or am i missing a terraform configuration flag that forces a strict comparison against the API response payload? i need to resolve this before deploying my next set of open_messaging templates. any insights on debugging this state mismatch would be appreciated.