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

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?

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.

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

1. Call GET /api/v2/routing/queues/{queueId}.
2. Compare member_count and wrap_up_code against your config.
3. Ignore Terraform warnings if the data matches.

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

terraform force-unlock <LOCK_ID>

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.