Quick question about handling idempotency keys or conflict resolution when provisioning genesyscloud_auth_division resources via the Genesys Cloud Terraform provider.
I am writing a k6 script to simulate high-concurrency provisioning scenarios for our infrastructure pipeline. The script spins up multiple virtual users, each attempting to create a distinct genesyscloud_auth_division resource using the Terraform CLI wrapped in a bash subshell. Under heavy load (50 VUs), the terraform apply commands frequently fail with a 409 Conflict error. The error suggests that a resource with the same name already exists, even though I am using unique suffixes generated from the k6 iteration ID.
Here is the error output:
Error: Conflict occurred while creating resource
code: 409
message: A resource with the same name already exists in the organization.
The Terraform configuration is straightforward:
resource "genesyscloud_auth_division" "load_test_div" {
name = "k6-test-division-${var.iteration_id}"
description = "Division for k6 load test ${var.iteration_id}"
}
I suspect the race condition occurs because the Genesys Cloud API processes the create requests asynchronously, and the uniqueness check happens before the previous request has fully committed or been indexed. I need a code-level workaround or a specific Terraform provider argument to handle this. Should I be using a custom retry logic in the k6 script, or is there a way to force the provider to handle the 409 by checking for existence first? I cannot simply add a random string to the name as it breaks our cleanup scripts. Any insights on how to stabilize this under load would be appreciated.