WebRTC softphone provisioning via Terraform provider 1.14.1 returning 409 on routing_user audio_device binding

The 02:00 JST nightly pipeline kept failing on the WebRTC softphone rollout. Terraform 1.8.2 paired with the nice-cxone provider 1.14.1 throws a 409 Conflict whenever the nice_cxone_routing_user resource attempts to set webrtc_enabled = true alongside a custom audio_device profile. The error hits the /api/v2/users/{userId}/webrtc endpoint directly. Payload validation rejects the device_id reference because the console still lists the legacy SIP trunk binding as active.

Ran a terraform plan -refresh-only first. State file shows the attribute is already managed, yet the API response returns a conflict message. Tried clearing the local state with terraform state rm nice_cxone_routing_user.agent_pool_04. Applied again. Same 409.

Checked the Architect flow configuration. The routing user profile inherits a default interaction flow that forces SIP fallback. Disabled the fallback flag in the console, waited ten minutes for cache propagation, and triggered a manual apply. Provider logs show the PUT request succeeds initially, but the subsequent GET sync pulls back a mismatched audio_device hash. State drift resumes immediately.

Provider documentation mentions the webrtc_softphone resource should handle the decoupling automatically. The schema in 1.14.1 doesn’t expose a force_unbind_legacy argument. Rolling back to provider 1.12.0 bypasses the 409, but it drops the audio_device attribute entirely. It’s a dead end since Genesys Cloud API v2 requires that field for proper codec negotiation on the new softphone client.

The core issue remains whether the provider should handle the legacy unbind sequence automatically, or if a separate API call is required before the routing user resource applies. Pipeline runs on a self-hosted runner in Tokyo. Network latency to the CXone edge sits around 45ms. Retries don’t help. The console UI is doing jack all to clear the legacy binding. You’ll see the retry loop just burn through the rate limit. The conflict appears tied to how the provider maps the audio_device JSON block to the internal UUID registry.

resource "nice_cxone_routing_user" "agent_webrtc" {
 email = "agent04@corp.jp"
 webrtc_enabled = true
 audio_device {
 device_id = "softphone_v2_codec_opus"
 fallback = false
 }
}
{
 "code": "conflict",
 "message": "User webRTC configuration cannot be updated while legacy softphone profile is assigned",
 "status": 409,
 "trace_id": "tokyo-prod-8842-xf"
}

The PUT payload includes the correct org_id and tenant headers. Provider debug logs show the API returning a 200 on the first attempt, then a 409 on the state refresh sync. Something is locking the user profile at the database level during the IaC reconcile cycle.