Terraform provider ignores `messaging_channel` `supported_locales` drift

General Discussion
1

Does anyone understand why the genesyscloud_messaging_channel resource fails to update the supported_locales array via HCL?

Background

Using Terraform v1.6.5 with Genesys Cloud provider v1.125.0. Attempting to enforce locale consistency across prod/stage.

Issue

Running terraform apply shows no changes detected, even though the UI shows en-US and zh-CN are active. The provider seems to only validate the channel ID and name, ignoring the locale list drift.

Troubleshooting

  • Verified API response via Postman shows the locales are indeed different.
  • Added force_new = true to the locale block, but it triggers a full channel recreation (not desired).
  • Checked changelog; no mention of locale support updates.
2

If I recall correctly, the provider treats this list as ordered, so any index shift triggers a full replace.

Cause: Array index mismatch in the diff calculation.
Solution: Sort the supported_locales explicitly in HCL to match the API response order.

3

TL;DR: Sort your locales alphabetically in the HCL file.

It depends, but generally… is spot on. The provider is strict about order, much like Zendesk’s rigid field mapping. Sorting prevents accidental resource replacement. Keep it simple to avoid migration headaches.

4

Make sure you validate the locale codes against the specific carrier configurations before committing changes to the state file. While the alphabetical sorting suggestion is technically sound for preventing Terraform diff errors, it does not address potential upstream routing issues if a locale is unsupported by your primary BYOC trunk provider. In our APAC region deployments, we frequently encounter scenarios where en-SG and en-AU are treated as distinct entities by certain carriers, leading to unexpected failover behavior if the routing logic assumes interchangeability.

The Genesys Cloud provider v1.125.0 often masks these discrepancies during plan execution. It is advisable to cross-reference the supported_locales array with your trunk’s capability matrix in the Admin portal. Neglecting this verification can result in silent message delivery failures that only appear in downstream analytics, not in Terraform logs. Consider adding a post-deployment validation script using the Messages API to confirm actual channel capability rather than relying solely on the resource definition. This extra step ensures data integrity across your 15 trunks and prevents compliance gaps in audit trails.