Could use a hand troubleshooting this weird state drift with predictive routing queues. running terraform apply in sydney region using provider v1.18. the config looks fine locally but the api keeps rejecting the update or silently changing values after apply.
resource “genesyscloud_routing_queue” “main” {
name = “support-predictive”
description = “managed by tf”
routing_type = “PREDICTIVE”
member_flow_id = var.member_flow_id
no_answer_flow_id = var.no_answer_flow_id
timeout_action = “DELETE”
wrap_up_timeout = 60
skills {
id = var.skill_id
priority = 1
rank = 1
type = “HARD”
}
utilizations {
id = “default”
default = 70
}
}
the error is intermittent. sometimes it works. sometimes i get a 409 conflict saying the queue is locked or being updated by another process. but we are the only ones touching this queue. the logs show the api is returning a different utilizations block than what i sent. specifically the default value changes from 70 to 100 in the state file after apply, even though the api response in the debug logs shows 70.
is this a known bug with the predictive routing utilizations field? or am i missing a depends_on clause? the member flow is also managed by terraform. tried adding depends_on = [genesyscloud_flow.member] but no change.
also the queue depth metric in analytics seems off. showing 0 agents available when the wfm schedule says 10 should be logged in. but that might be a separate issue. for now just want the terraform state to match reality.
anyone else seeing this with v1.18? or should i downgrade to v1.17?
This seems like a classic attribute mismatch in the provider schema rather than a genuine API rejection.
routing_type = “PREDICTIVE”
The API expects PREDICTIVE but Terraform often normalizes this; check if your no_answer_flow_id is actually null or pointing to a deleted flow, as that silently reverts the config.
resource “genesyscloud_routing_queue” “main” {
name = “support-predictive”
description = “managed by tf”
routing_type = “PREDICTIVE”
member_flow_id = var.member_flow_id
no_answer_flow_id = var.no_answer_flow_id
Explicitly manage read-only attributes to prevent drift
long_description = “Predictive routing queue for support”
Ensure wrap up code is defined if required by your org
wrap_up_code {
code = “10”
name = “Standard Wrap Up”
}
}
> need some help troubleshooting a weird state drift with predictive routing queues... api keeps rejecting the update or silently changing values after apply.
The suggestion above about `no_answer_flow_id` is spot on for null pointer issues, but in my experience with weekly schedule syncs and queue configurations, the real culprit is often the `long_description` or `wrap_up_code` fields. The Genesys Cloud API is notorious for auto-populating these if they are empty, causing Terraform to see a "drift" even though the functional routing hasn't changed.
When you run `terraform plan` after the initial apply, does it flag changes to `long_description` or `wrap_up_code`? If so, explicitly defining them in your resource block stops the provider from trying to "fix" what the API auto-filled. Also, check your `member_flow_id`. Predictive queues require a very specific flow structure. If the flow isn't published or is missing the correct action groups, the API might revert the `routing_type` back to `MANUAL` or `LONGEST_AVAILABLE_AGENT` as a safety measure.
Another thing to verify is the `outbound_email_address` and `outbound_email_subject`. These often get populated by system defaults if left blank. Pinning them down in the HCL file usually stabilizes the state. Run a `terraform refresh` to pull the current state, then compare it against your desired config. This usually highlights which "hidden" fields are causing the silent reverts.