Running terraform plan in our AU-East environment shows constant drift on genesyscloud_ai_nlp resources. The remote state differs from the HCL configuration specifically regarding the version attribute. We are attempting to pin the NLP model version to ensure deterministic deployment across dev, staging, and prod. However, Genesys Cloud API seems to auto-increment or ignore the pinned version during apply, causing perpetual drift detection.
Environment:
Provider: genesyscloud/genesyscloud v3.42.0
Region: ap-southeast-2 (Sydney)
Terraform: 1.7.4
State: Remote S3 backend
The HCL block is minimal and explicit:
resource "genesyscloud_ai_nlp" "customer_intent_model" {
name = "Prod-Customer-Intent-Model"
description = "Pinned NLP model for CX as Code pipeline"
language = "en-AU"
# Attempting to pin version to avoid unexpected schema changes
version = "v2.1.0"
settings {
min_confidence_threshold = 0.75
enable_entity_extraction = true
}
}
Error output from terraform apply:
Terraform will perform the following actions:
# genesyscloud_ai_nlp.customer_intent_model will be updated in-place
~ resource "genesyscloud_ai_nlp" "customer_intent_model" {
~ version = "v2.1.0" -> "v2.1.1"
... other attributes unchanged ...
}
Plan: 0 to add, 1 to change, 0 to destroy.
The API response for GET /api/v2/ai/nlp/{nlpId} returns version: v2.1.1 even though the request body specified v2.1.0. Is there a known issue with version pinning for NLP models in the current provider release? Or is this behavior intentional due to background model retraining jobs overriding the static version? Need a stable state for our CI/CD gate checks.
The best way to fix this is to use terraform import genesyscloud_ai_nlp.my_model <model_id> to sync the state file with the live version, just like with scripts. This stops the constant drift by aligning your local state with what Genesys Cloud actually has.
Cause:
The Genesys Cloud NLP model version attribute often behaves as a read-only or system-managed field in certain API versions. When Terraform attempts to write a specific version string, the API might ignore it and push the latest stable model, or it might auto-increment based on internal training cycles. This creates a perpetual drift loop because the state file records what you wanted, but the cloud holds what the system decided. Importing the state, as suggested, masks the problem but doesn’t fix the underlying configuration mismatch.
Solution:
Instead of fighting the version pinning directly in the resource definition, try using the lifecycle block to ignore changes to the version attribute during non-major updates. This allows you to manage the model structure without Terraform constantly trying to revert the version number.
resource "genesyscloud_ai_nlp" "my_model" {
name = "Customer Support Bot"
description = "Primary NLP model for intent classification"
# Add this lifecycle block to prevent drift on version
lifecycle {
ignore_changes = [
version
]
}
}
If you absolutely need version control for compliance, consider managing the NLP model version through a separate data source or a post-deployment script rather than the main resource definition. This keeps your infrastructure code clean while allowing the AI service to handle its own versioning logic. We’ve seen this pattern stabilize deployments in our weekly scheduling tool integrations where external API versions shift unexpectedly.