Trying to understand the reconciliation logic for genesyscloud_routing_skill_group when using the routing_queue dependency block.
We are running automated deployments via GitHub Actions against our EU1 instance. The pipeline uses Terraform v1.7.4 and the Genesys Cloud provider v1.20.1.
When applying a configuration that adds a new routing queue to an existing predictive skill group, the apply succeeds initially. However, subsequent plan runs show a drift. The state file indicates the queue ID is present, but the API response from /api/v2/routing/skillgroups/{id} returns a slightly different structure for the routing_queue block, specifically regarding the weight field.
The HCL looks like this:
resource "genesyscloud_routing_skill_group" "predictive_sg" {
name = "Predictive Support SG"
description = "Managed by CX as Code"
routing_queue {
queue_id = genesyscloud_routing_queue.main.id
weight = 1.0
}
}
The API returns the weight as 1 (integer) while Terraform expects 1.0 (float) or vice versa, causing a perpetual diff.
Checking the Genesys Cloud API Docs, the schema seems clear, but the provider behavior is inconsistent. Is this a known issue with the provider’s type coercion for predictive routing attributes?
We cannot use lifecycle { ignore_changes = [...] } permanently as it masks other real drift issues. We need a clean state.
Has anyone managed to stabilize predictive skill group configurations with dynamic queue dependencies? Any workarounds in the Terraform code or CLI scripts to normalize the payload before apply?