We manage our entire GC org configuration through CX as Code (Terraform provider genesyscloud v1.41.0). Our CI/CD pipeline runs terraform plan and terraform apply on every merge to main.
Starting yesterday, any terraform apply that modifies a genesyscloud_routing_queue resource fails with a 409 Conflict error:
Error: Failed to update routing queue 4f8a2c1e-bb34-4d8e-9c17-2a1b3c4d5e6f
PUT /api/v2/routing/queues/4f8a2c1e-bb34-4d8e-9c17-2a1b3c4d5e6f
HTTP 409: Resource version conflict. The resource has been modified by another process.
Nothing else is modifying these queues. No one is making manual changes in the admin UI. The Terraform state file shows version: 14 for this queue, but the API is returning version: 16.
We tried terraform refresh to sync state, and the apply works once but then fails again on the next run 20 minutes later. Something is incrementing the queue version outside of Terraform.
Has anyone tracked down what internal GC process auto-increments routing queue versions?
Ugh, this one bit us hard last year. The version increment you are seeing is caused by the WFM scheduling engine. Every time WFM publishes a schedule or an intraday reforecast runs, it internally updates the queue’s memberCount property. That write operation bumps the queue resource version even though nothing visible in the queue configuration actually changed.
The Terraform provider does a read-modify-write cycle using the version for optimistic locking. By the time your apply sends the PUT request, WFM has already bumped the version and you get the 409.
The only real fix is to add a retry loop in your CI pipeline. Something like:
for i in 1 2 3; do
terraform apply -auto-approve && break
echo "Retry $i: refreshing state..."
terraform refresh
sleep 10
done
It is ugly but it works. There is a feature request on the Genesys Ideas portal to exclude WFM-internal writes from the version counter, but last I checked it had not been prioritized.
We have same problem in our environment with 800 agents. The retry approach works for simple cases, but in our CI/CD pipeline we cannot simply retry because we run multiple Terraform workspaces in parallel for different queue groups.
What we did instead is split the queue configuration into two layers. The first layer manages the queue definition - name, description, skill groups, ACW settings. The second layer manages the queue membership using the genesyscloud_routing_queue_member resource separately.
The WFM version bump only affects the parent queue resource, not the individual member resources. By separating them, the member changes apply cleanly and the parent queue definition rarely changes, so the 409 window is much smaller.
We also added lifecycle { ignore_changes = [member_count] } to the queue resource definition, which prevents Terraform from detecting the WFM-caused drift as a change that needs to be applied.
Both approaches above are valid, but I would like to add some context for anyone evaluating this from an infrastructure-as-code maturity perspective.
The lifecycle { ignore_changes } meta-argument is the correct Terraform-native solution. However, be aware that the Genesys Cloud Terraform provider v1.41.0 has a separate bug where ignore_changes does not work correctly on nested attributes within the routing_queue resource. This was fixed in v1.43.0.
If you are on v1.41.0 specifically, upgrade to at least v1.43.0 before relying on ignore_changes. Otherwise the provider will still attempt to send the full resource payload on every apply, which reintroduces the 409 race condition.
The provider changelog for v1.43.0 explicitly calls out “Fixed optimistic locking handling for routing queue updates” as a resolved issue.