Why is this setting causing a conflict during automated deployment?
Attempting to provision a new Predictive Routing queue via Terraform provider v2.1.0. The pipeline fails on the genesyscloud_routing_queue resource.
resource "genesyscloud_routing_queue" "support_queue" {
name = "Support_Queue_AU"
description = "Managed by IaC"
queue_members {
member_id = var.agent_id
member_type = "AGENT"
skill_level = 5
}
}
Error returned:
“Error creating routing queue: 409 Conflict. The requested resource is already associated with another entity.”
The queue ID does not exist in the environment. Verified via GC CLI (genesys cloud routing queues list). No existing queue matches the name.
Suspect issue with queue_members block handling in the provider. If the agent is already in a different queue, does the provider throw a 409 before creating the queue?
Documentation states:
“Queue members can be added or removed after queue creation. Ensure the agent is not already assigned to a conflicting skill group.”
This seems unrelated to skill groups. The agent has no other queue memberships.
Steps taken:
- Destroyed state (
terraform state rm).
- Re-applied.
- Same 409 error.
API trace shows the POST request to /api/v2/routing/queues includes the queueMembers array in the body. The response body returns a duplicate key error on memberId.
Is this a known limitation in the Terraform provider when adding members during creation? Or is there a race condition with the underlying Genesys Cloud API?
Environment:
- Genesys Cloud Region: Australia (Sydney)
- Terraform Provider: 2.1.0
- GC CLI: 1.5.4
Looking for a workaround or correct HCL syntax to separate queue creation from member assignment.
I typically get around this by ensuring the queue exists before adding members, as Genesys Cloud handles queue creation and membership differently than Zendesk’s single-step ticket assignment. In Zendesk, you might assign a ticket to an agent and they are instantly part of the workflow. In Genesys Cloud, the genesyscloud_routing_queue resource often conflicts if the queue_members block is included in the initial creation call when the agent or skill dependencies aren’t fully resolved or if the queue ID is being referenced incorrectly.
The 409 Conflict typically indicates that the queue is being created with members in a state that conflicts with existing data or required pre-conditions. A cleaner approach for migration scripts is to split the resource definition. First, create the queue without members to ensure the base configuration is valid. Then, use a separate resource or a depends_on meta-argument to add the members.
Try this structure:
resource "genesyscloud_routing_queue" "support_queue" {
name = "Support_Queue_AU"
description = "Managed by IaC"
# Remove queue_members block here for initial creation
}
resource "genesyscloud_routing_queue_member" "agent_member" {
queue_id = genesyscloud_routing_queue.support_queue.id
member_id = var.agent_id
type = "AGENT"
skill_levels {
skill_id = var.skill_id # Ensure this skill exists
level = 5
}
depends_on = [genesyscloud_routing_queue.support_queue]
}
This mirrors how we handle Zendesk ticket forms versus agent assignments. You define the container first, then the participants. Check your var.skill_id as well; if the skill referenced in skill_levels doesn’t exist yet, the API will throw a conflict. Make sure your Terraform state reflects all prerequisite objects before attempting to link them. This separation of concerns usually stabilizes the IaC pipeline significantly during migrations.
Have you tried separating the queue definition from the membership assignment in your Terraform state to avoid the race condition?
The 409 conflict typically occurs because the platform attempts to resolve the member_id before the queue resource is fully initialized in the backend. When running load tests or automated deployments, concurrent requests to create a resource and its children simultaneously often hit a transient lock. The documentation suggests decoupling these operations. Instead of nesting queue_members inside the genesyscloud_routing_queue resource, use a separate genesyscloud_routing_queue_member resource. This allows the queue to be created first, ensuring the ID is valid before the membership API is called.
resource "genesyscloud_routing_queue" "support_queue" {
name = "Support_Queue_AU"
description = "Managed by IaC"
}
resource "genesyscloud_routing_queue_member" "agent_member" {
queue_id = genesyscloud_routing_queue.support_queue.id
member_id = var.agent_id
member_type = "AGENT"
skill_level = 5
}
This pattern aligns better with how the API handles capacity planning and resource dependencies. During JMeter stress tests, we observed that nested blocks caused higher latency and failure rates due to implicit dependency checks. By flattening the structure, you give the API a clear order of operations. It also makes it easier to manage member lists independently if you need to swap agents without recreating the entire queue. Try this approach in your next pipeline run.