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

General Discussion
1

Error: error reading Routing Queue (id: 12345): GET https://api.mypurecloud.com/api/v2/routing/queues/12345: 409 Conflict

State lock error: LockInfo{Path: genesyscloud_routing_queue.main, ID: ...}

I am running terraform plan on a Windows 11 machine with Terraform v1.6.4 and the Genesys Cloud provider v1.12.0. The plan consistently reports drift on genesyscloud_routing_queue resources, claiming attributes like outbound_call_appearance have changed. However, my local state matches the API response exactly when I hit the endpoint via Postman.

The 409 error suggests a state lock issue, but I have already run terraform force-unlock with the lock ID. The lock metadata in the state file seems stale. Is this a known issue with the provider handling concurrent reads during plan phases?

Here is the resource block:

resource "genesyscloud_routing_queue" "main" {
 name = "Support Queue"
 description = "Main support queue"
 outbound_call_appearance = "system"
}

The plan output shows:

~ resource "genesyscloud_routing_queue" "main" {
 ~ outbound_call_appearance = "system" -> (known after apply)
 }

Why is the provider treating this as drift when the value is static? Am I missing a lifecycle rule or is this a bug in the diff calculation logic?

2

Yep, this is a known issue…

I am running terraform plan on a Windows 11 machine… consistently reports drift

The 409 conflict usually stems from concurrent state edits, not drift. Run terraform force-unlock <LOCK_ID> to clear the stale lock. Then, ensure your provider uses the genesyscloud_routing_queue data source to fetch the current state before updating, avoiding write conflicts.

3

I typically get around this by bypassing Terraform state entirely. Use the Analytics API to export queue_statistics via Python. The 409 Conflict indicates backend sync lag, not true drift.

  1. Call GET /api/v2/analytics/queues/details/query.
  2. Compare member_count and wrap_up_code against your config.
  3. Ignore Terraform warnings if the data matches.
4

this looks like a stale lock, not drift. run terraform force-unlock <LOCK_ID> to clear it.

terraform force-unlock <LOCK_ID>
5

This is caused by concurrent state edits rather than actual drift. The suggestion above is correct, but ensure you run terraform force-unlock <LOCK_ID> to clear the stale lock before retrying.