Can anyone clarify the idempotency behavior for the genesyscloud_bot resource when updating NLU intents via Terraform?
Running into a 409 Conflict error during CI/CD pipeline execution. The error suggests a version mismatch, but the bot_version_id variable is static in the state file. The issue appears when modifying the intent training phrases through the API wrapper used by the provider.
Environment:
- Terraform Provider v1.2.0
- Genesys Cloud API v2
- Edge: APAC
- Pipeline: GitHub Actions
The specific endpoint failing is PUT /api/v2/bots/{botId}/versions/{versionId}/intents. The response body contains:
{"errors":[{"code":"version_conflict","message":"The resource version has changed since the last read. Please refresh your view and try again."}]}
Configuration snippet:
resource "genesyscloud_bot" "main" {
name = "Support-Bot-Prod"
description = "Auto-generated"
bot_version {
name = "v1.0.5"
intents {
name = "greeting"
training_phrases {
text = "Hello"
}
}
}
}
The pipeline runs sequentially. No parallel updates. State locking is enabled. Is there a known issue with the provider handling version tokens for NLU sub-resources? Or is this a limitation of the underlying REST API requiring explicit version refresh logic that the HCL abstraction hides?
Yep, this is a known issue with the provider not handling version increments correctly during NLU updates. You need to add a depends_on to the bot version resource or manually bump the version in the state. Do not ignore the version mismatch or the state will drift permanently.
Have you tried explicitly defining the depends_on relationship between the bot definition and the NLU intent resources in your Terraform configuration? The suggestion above about handling version increments is spot on, but if you are migrating from Zendesk, you might be used to a simpler update mechanism where the platform handles versioning automatically. In Genesys Cloud, the bot resource and its associated NLU intents are tightly coupled with the version lifecycle.
When updating intent training phrases, the provider needs to know that the bot definition itself has changed or that a new version should be triggered. Without this dependency, the API calls might race, leading to the 409 Conflict error you are seeing. Here is how you can structure your Terraform code to ensure proper ordering:
resource "genesyscloud_bot" "my_bot" {
name = "MyBot"
description = "Migrated from Zendesk"
}
resource "genesyscloud_bot_intent" "my_intent" {
bot_id = genesyscloud_bot.my_bot.id
name = "OrderStatus"
language = "en"
# Ensure this depends on the bot being created/updated first
depends_on = [genesyscloud_bot.my_bot]
}
Additionally, check if your CI/CD pipeline is locking the state file correctly. A common fix is to add a short sleep or retry logic in your pipeline script if the 409 error occurs, allowing the Genesys Cloud backend to finish processing the previous version update. This mimics the delay you might have seen in Zendesk’s API rate limiting.
- Bot versioning lifecycle
- Terraform provider dependencies
- API conflict resolution strategies
- Zendesk vs. Genesys Cloud migration patterns