Looking for advice on handling validation drift in genesyscloud_quality_evaluation_resource. Provider 1.46.1 throws error “Weight must be between 0 and 100” despite HCL defining weight = 50.0. The API accepts it, but plan shows perpetual drift on evaluation_step weight field. Is this a float precision bug in the provider or a schema mismatch in AU1?
make sure you verify the actual data type being sent in the json payload versus what the hcl provider expects. this is a common issue with the genesys cloud terraform provider where float precision gets mishandled during the plan phase. the api often accepts integers or floats interchangeably, but the provider’s schema validation can be strict about the exact type definition.
check your genesyscloud_quality_evaluation_resource block. if you are using weight = 50.0, try changing it to weight = 50 (integer) or explicitly casting it. sometimes the provider sends 50.0000000001 due to floating point arithmetic errors, causing the drift detection to flag it as different from the stored 50.
here is a quick snippet to test:
resource "genesyscloud_quality_evaluation_resource" "eval" {
name = "test_eval"
evaluation_step {
name = "step1"
weight = 50 # use integer instead of float
type = "boolean"
}
}
if that doesn’t resolve it, check the api response directly via postman or the genesys cloud api explorer. compare the raw json returned by the get endpoint with what terraform is storing in the state file. often the provider caches an older version of the schema. running terraform refresh might help, but usually, the issue lies in how the weight is serialized.
also, look at the provider version changelog for 1.46.1. there were some fixes around quality evaluation schemas in recent patches. if you are on an older version, consider upgrading to the latest stable release. this specific drift issue was reported in the community forums last month and was linked to a mismatch in how the api handles decimal places for weights.
another workaround is to use the ignore_changes lifecycle block if you cannot fix the type mismatch immediately, though this is not recommended for long term stability.
lifecycle {
ignore_changes = [evaluation_step[0].weight]
}
this prevents the drift detection from flagging the field, but be cautious as it might hide real configuration errors. always validate the weight value against the api documentation to ensure it falls within the accepted range and format.