Error: Error updating Architect Flow: POST /api/v2/architect/flows: 409 Conflict
Response body: {“errors”:[{“code”:“CONFLICT”,“message”:“The resource has been modified by another user since you last retrieved it.”}]}
Context:
- Genesys Cloud Terraform Provider: 1.22.0
- Terraform Version: 1.7.5
- Environment: Production (US-East)
- Deployment Tool: GitHub Actions (self-hosted runner, Sydney timezone)
The CI/CD pipeline triggers a terraform apply on a scheduled basis to sync Architect flows from the Git repository. The flow contains a “Make Webhook” action pointing to an external NICE CXone connector. The webhook configuration in the HCL file remains static across commits. However, the apply fails consistently with a 409 Conflict on the webhook node definition.
Investigation shows that the etag stored in the Terraform state file does not match the current etag in the Genesys Cloud API. The state file shows the last modified timestamp as 10 minutes ago, but the API returns a newer etag. No manual changes were made to the flow in the UI during this window.
From Genesys Cloud Documentation:
“If the resource has been modified by another process or user, the API returns a 409 Conflict. You must retrieve the latest version of the resource and re-apply your changes.”
The issue appears to be related to how the provider handles the webhook block within the flow_version resource. It seems the provider is not correctly handling the optimistic locking mechanism for nested webhook objects when the parent flow has other concurrent updates (even if minor, like analytics tags).
Terraform HCL snippet:
resource "genesyscloud_flow" "main_flow" {
name = "Customer_Support_Flow"
description = "Main support routing flow"
flow_version {
# ... other nodes ...
node "webhook_call" {
type = "MakeWebhook"
# ... configuration ...
}
}
}
Is there a known workaround for this etag mismatch in the provider? Should I implement a retry mechanism in the GitHub Actions workflow, or is this a bug in the provider’s handling of webhook etags? The terraform plan shows no changes, but apply fails immediately.