Just noticed that applying the latest IaC changes for predictive routing triggers a conflict. Environment is US1. Provider version 1.12.4.
The resource genesyscloud_routing_email_domain fails during the apply phase when setting the predictive strategy. The error suggests an existing configuration clash, but the state file shows no prior resource for this specific identifier.
Error: Error creating routing email domain: POST /api/v2/routing/email/domains: 409 Conflict
Response body: {“errors”:[{“code”:“CONFLICT”,“message”:“A resource with this identifier already exists”}]}
Terraform plan shows no changes to the domain name. The conflict seems to stem from the underlying predictive routing engine holding a lock or a stale reference. Manual deletion via UI is not an option due to compliance locks.
Has the GC API changed behavior regarding identifier uniqueness for predictive domains recently? Need to know if this is a provider bug or an API-side constraint. Looking for a workaround to force the state sync without manual intervention.
Make sure you check if the email domain already exists in the Genesys Cloud instance before running the terraform apply. the 409 conflict usually means the resource is already there, even if your state file is empty or out of sync. this is common when resources are created manually in the UI or by a different pipeline.
you can verify this by hitting the api directly or adding a data source to read the existing config. here is a quick check using curl to see if the domain is already registered:
curl -X GET "https://api.us1.genesyscloud.com/api/v2/routing/email/domains" \
-H "Authorization: Bearer <your_token>"
if the domain is present, you need to import it into your state file instead of creating it. running terraform import genesyscloud_routing_email_domain.my_domain <domain_id> will fix the conflict.
also, keep an eye on the provider version. 1.12.4 is a bit older and might have bugs with conflict detection. upgrading to the latest stable release often helps with these edge cases.
another thing to watch out for is the predictive routing strategy settings. if the domain is linked to a specific skill group or strategy that is currently active, the api might block changes. try disabling the strategy temporarily or ensuring the domain is not in use by any active email routing rules.
load testing showed that concurrent writes to routing resources can cause transient conflicts too. if you are running multiple plans at once, serialize the applies. but for a simple 409, it’s almost always a state mismatch or a duplicate resource.
check the logs for the specific error message in the response body. sometimes the api gives more details about which field is conflicting. hope this helps clear up the issue.