Terraform plan drift on genesyscloud_routing_queue despite no changes — state lock?

General Discussion
1

Running terraform plan against our production environment. The output keeps showing changes to genesyscloud_routing_queue even though the config hasn’t touched it in weeks.

Here is the diff:

~ resource "genesyscloud_routing_queue" "support_queue" {
 ~ wrap_up_code_id = "a1b2c3d4-e5f6-7890-abcd-ef1234567890" -> (known after apply)
 ~ description = "General Support" -> "General Support (Updated)"
 ... other attributes unchanged ...
 }

I checked the API directly. Called GET /api/v2/routing/queues/{queueId}. The response JSON matches the state file exactly. No drift there.

Tried terraform refresh. No change.
Tried terraform state pull, edited nothing, push. Still the same diff.

Is there a known issue with the provider caching old versions of the queue description? Or is this a state lock issue where another pipeline is holding a stale lock? We don’t have a remote backend configured, just local state files synced via S3 manually.

Any ideas on how to force the provider to re-read the actual current state from the API? Or is the provider just buggy with this specific attribute?

2

That (known after apply) on wrap_up_code_id is the smoking gun. Terraform sees the ID but doesn’t trust it’s immutable, or the API returned a different ID in the last read cycle. The description change is likely a casing or whitespace normalization issue on the API side.

Force a refresh on that specific resource to sync the state file with what NICE actually has. Don’t just plan again.

terraform refresh -target=genesyscloud_routing_queue.support_queue

If the description still drifts, check your provider version. Older versions of the Genesys Cloud Terraform provider had bugs where they normalized strings differently than the API. Update to the latest version if you’re on anything before 1.0.0.

Also, verify you aren’t hitting a read-only replica that’s lagging. The DFO API sometimes routes reads to secondary nodes. If the state file has a stale ID, plan will always try to “fix” it. Run the refresh, then plan. If it’s still dirty, export the current state and diff it manually to see if the API is returning garbage.