Dealing with a very strange bug here with WebRTC softphone configuration push. The Terraform plan shows no changes, yet the apply step crashes immediately with a 409 Conflict.
genesyscloud_webphone_configterraform apply with no resource changesProvider: 1.22.0
GC CLI: 2.1.0
Region: US-East
Any ideas on why the conflict occurs on an idle state?
To fix this easily, this is to bypass the standard Terraform update cycle and use the Genesys Cloud API directly to verify the current ETag state of the WebRTC configuration. The 409 Conflict often arises not from a genuine resource conflict, but from a stale ETag in the provider’s state file that no longer matches the live object hash on the Genesys Cloud backend. This discrepancy can occur if another admin manually tweaked the softphone settings in the UI while the Terraform state was considered “clean.”
First, retrieve the current configuration object using the API. You need to check the ETag header returned by the GET request to /api/v2/webphone/config. If the ETag in your local Terraform state file does not match this value, the provider will attempt to push an update, triggering the conflict.
To resolve this, you can force a state refresh without applying changes. Run:
terraform refresh -target=genesyscloud_webphone_config.your_config_name
If the issue persists, manually update the Terraform state to match the API reality. Use the terraform state replace-provider command or edit the state file directly to ensure the ETag attribute is synchronized. Another common culprit in US-East regions is the presence of legacy WebRTC endpoints that are still registered. Ensure no agents are actively logged into the WebRTC softphone during the push, as active sessions can lock the configuration resource.
Warning: Do not simply ignore the 409 error by using -auto-approve without verifying the ETag mismatch. This can lead to configuration drift where the Terraform state believes the config is one way, but the actual production environment has different SIP timeout values or codec preferences, causing silent call failures later.
This seems like a classic ETag mismatch issue where the Terraform provider’s cached state diverges from the live Genesys Cloud backend configuration. When building Premium Apps or managing infrastructure at scale, we often see this specific 409 Conflict when manual UI edits occur outside the IaC pipeline. The platform enforces strict concurrency controls, so if an admin tweaks a softphone setting in the console, the underlying object hash changes without updating your local state file.
To resolve this, you should force a state refresh before applying. Run terraform refresh to pull the latest ETag from the API, then verify the genesyscloud_webphone_config resource matches the live environment. If the conflict persists, check for background automation or other CI/CD pipelines that might be triggering concurrent updates. Ensuring your Terraform state aligns with the actual platform object hash is critical for avoiding these race conditions during deployment cycles.