Messaging channel drift detection failing on apac byoc trunks

Need some troubleshooting help with a persistent drift issue we are seeing with our messaging channels across the 15 byoc trunks in the apac region. specifically, the terraform provider is flagging drift on the supported_locales attribute even though the configuration in the state file matches exactly what is visible in the admin console. we are running terraform provider version 1.2.4 and genesys cloud platform release 2024-03.1.

when we run terraform plan, it suggests changing the locale codes from ["en-SG", "zh-CN"] to ["en-SG", "zh-CN"] - essentially no change - yet the plan output indicates a modification is required. this is happening consistently for our whatsapp and sms channels tied to the singapore and shanghai byoc connections. we have verified the carrier configurations directly with our telco partners, and they confirm the locale support is static and matches our config.

we tried refreshing the state and even destroying and recreating the resource in a sandbox environment, but the drift persists. interestingly, the voice channels on the same trunks do not exhibit this behavior, which makes us suspect this is specific to how the messaging api handles locale validation or caching. we are also seeing intermittent 409 conflict errors when attempting to update these channels via the rest api, suggesting some internal locking or asynchronous validation might be interfering with the terraform state reconciliation.

has anyone else encountered similar issues with the messaging channel resource in the terraform provider? we are trying to automate our trunk provisioning and this drift is blocking our ci/cd pipeline. any insights into whether this is a known bug in the provider or a quirk with the apac region’s messaging infrastructure would be appreciated. we are currently working around it by using lifecycle { ignore_changes = [supported_locales] }, but that feels like a band-aid and we would prefer a proper resolution to ensure configuration integrity.

If I remember correctly, this specific drift issue with supported_locales on BYOC trunks is a known quirk in the Genesys Cloud Terraform provider, especially around version 1.2.4. The API often returns locale data in a slightly different format or order than what the state file expects, causing Terraform to think a change is needed even when the functional configuration is identical.

From a WFM perspective, we see similar “ghost” changes when schedule adherence rules are updated via the UI but not reflected in the IaC state. The fix usually involves ignoring the specific attribute that is causing the noise. You can add a lifecycle block to your resource definition to tell Terraform to stop checking that particular field.

Here is how you can adjust your configuration:

resource "genesyscloud_routing_email_route" "apac_route" {
 # ... other config ...
 supported_locales = ["en-US", "ja-JP"]

 lifecycle {
 ignore_changes = [
 supported_locales # Ignore drift on this field
 ]
 }
}

Be extremely careful when using ignore_changes as it can mask legitimate configuration drift if the underlying API behavior changes in future platform releases. It is essentially telling Terraform, “Trust me, I know this is different, but it does not matter.”

Another approach is to pin the provider version if you are not ready to upgrade, as newer versions of the provider (1.5+) have improved handling of array-based attributes like locales. If you are stuck on 1.2.4 due to other dependencies, the lifecycle block is your best bet to keep your CI/CD pipelines green while the WFM team focuses on publishing those weekly schedules without interruption. We deal with enough chaos during peak publishing times without Terraform crying wolf on every plan run.