Observing a persistent state drift issue with BYOC Edge resources in the Genesys Cloud Terraform provider (v1.15.4). The deployment pipeline runs via GitHub Actions on a nightly schedule to enforce infrastructure-as-code compliance.
The specific problem relates to genesyscloud_byoc_edge resources where the sip_settings block contains TLS certificate references. When the certificate is rotated in the certificate store, the Terraform plan detects a change, but the subsequent apply fails to reconcile the state correctly.
Error output:
Error: Error updating BYOC Edge "prod-edge-au": 400 Bad Request
Message: "Failed to update SIP settings. Certificate chain validation failed for provided cert_id."
The HCL configuration:
resource "genesyscloud_byoc_edge" "prod_edge" {
name = "prod-edge-au"
sip_settings {
sip_trunk {
name = "primary-trunk"
host = "sip.vendor.com"
tls_certificate_id = var.tls_cert_id
}
}
}
The variable var.tls_cert_id is dynamically resolved from the latest certificate version in the store. The API returns 400 because the certificate ID passed in the update payload does not match the expected format or the certificate is not yet fully propagated in the backend validation service.
Key observations:
- Manual update via UI succeeds immediately after cert rotation.
- Terraform apply fails consistently with 400.
- Reading the state (
terraform refresh) shows the old certificate ID, but the plan still wants to update.
Is there a known limitation with the provider regarding TLS cert ID references in BYOC edges? Or is there a specific API endpoint sequence required to validate the cert before updating the edge config? The standard genesyscloud_routing_edge documentation does not cover this edge case.
Environment:
- Provider: v1.15.4
- Genesys Cloud Org: AU1
- Terraform: 1.6.5
- CI/CD: GitHub Actions
Need a reliable way to handle cert rotations without manual intervention or state corruption.