Quick question about handling state drift with the genesyscloud_messaging_facebook resource in Terraform. We are seeing persistent diffs during terraform plan where the provider claims the webhook_url has changed, even though the value in the state file matches the value defined in the HCL.
Context:
- Terraform v1.8.5
- Genesys Cloud Provider v1.24.1
- Environment: Production (AWS GovCloud region, though this is just the provider config)
- Resource:
genesyscloud_messaging_facebook
The issue appears to be related to how the provider fetches the current state of the Facebook integration. The API response for the integration details seems to return a normalized URL (e.g., https://api.mypurecloud.com/api/v2/messaging/integrations/facebook/...), but the state file stores the raw webhook URL provided during creation. When Terraform compares the two, it sees a difference and attempts to update the resource, which fails because the Facebook app configuration is managed externally and immutable from this side.
Here is the relevant snippet:
resource "genesyscloud_messaging_facebook" "primary_fb" {
name = "Primary Facebook Messenger"
app_id = var.fb_app_id
app_secret = var.fb_app_secret
webhook_url = "https://hooks.myservice.com/gc/fb"
enabled = true
}
The webhook_url in state is https://hooks.myservice.com/gc/fb. The API returns https://hooks.myservice.com/gc/fb as well, but the diff shows:
~ resource "genesyscloud_messaging_facebook" "primary_fb" {
~ webhook_url = "https://hooks.myservice.com/gc/fb" -> "https://api.mypurecloud.com/api/v2/messaging/integrations/facebook/12345/webhook"
}
This suggests the provider is incorrectly mapping the internal endpoint to the webhook_url attribute during read operations. We have tried using lifecycle { ignore_changes = [webhook_url] }, but this prevents legitimate updates if the webhook endpoint changes in our infrastructure.
Is this a known bug in the 1.24.x provider line? We are considering pinning to an older version, but we need the latest fixes for the analytics reporting resources. Any workarounds or confirmation that this is a read-path bug would be appreciated.