When attempting to create a civo_dns_domain_record with a name of the format foo.bar.baz, and there is an existing civo_dns_domain_name with namebar.baz, the provider truncates the domain record's name value quietly to foo. The docs do point out that this is the expected input for this field, so some of this is user error, but it's an honest mistake to make, IMO.
This results in a permanent diff on every subsequent terraform plan.
What I would expect:
Initial terraform apply fails with an invalid input error.
Screenshots
Sample code:
terraform {
required_providers {
civo = {
source = "civo/civo"
version = "1.0.41"
}
}
}
provider "civo" {
}
resource "civo_dns_domain_name" "civo-478" {
name = "bar.baz"
}
resource "civo_dns_domain_record" "record_74_220_31_243" {
domain_id = civo_dns_domain_name.civo-478.id
name = "api-stg.bar.baz"
value = "74.220.31.244"
type = "A"
ttl = 600
}
First apply succeeds, thereafter terraform plan shows the following:
guin terraform-programs/civo-478🦉 terraform plan
civo_dns_domain_name.civo-478: Refreshing state... [id=c446be04-cae0-4234-8ed0-3c70cdd37ccc]
civo_dns_domain_record.record_74_220_31_243: Refreshing state... [id=31afa1d0-8832-4541-84fd-0f7d20a60e45]
Terraform used the selected providers to generate the following execution plan.
Resource actions are indicated with the following symbols:
~ update in-place
Terraform will perform the following actions:
# civo_dns_domain_record.record_74_220_31_243 will be updated in-place
~ resource "civo_dns_domain_record" "record_74_220_31_243" {
id = "31afa1d0-8832-4541-84fd-0f7d20a60e45"
~ name = "api-stg" -> "api-stg.bar.baz"
# (7 unchanged attributes hidden)
}
Plan: 0 to add, 1 to change, 0 to destroy.
Output of Terraform version
terraform version
Terraform v1.5.7
on darwin_arm64
+ provider registry.terraform.io/civo/civo v1.0.41
Description
Situation:
When attempting to create a
civo_dns_domain_recordwith anameof the formatfoo.bar.baz, and there is an existingcivo_dns_domain_namewithnamebar.baz, the provider truncates the domain record'snamevalue quietly tofoo. The docs do point out that this is the expected input for this field, so some of this is user error, but it's an honest mistake to make, IMO.This results in a permanent diff on every subsequent
terraform plan.What I would expect: Initial
terraform applyfails with an invalid input error.Screenshots
Sample code:
First apply succeeds, thereafter
terraform planshows the following:Output of Terraform version
Additional information
No response