terraform-provider-fastly
terraform-provider-fastly copied to clipboard
Problems modifying stale_if_error
Terraform Version
Terraform v1.7.4
on darwin_arm64
+ provider registry.terraform.io/datadog/datadog v3.36.1
+ provider registry.terraform.io/fastly/fastly v5.6.0
+ provider registry.terraform.io/hashicorp/google v4.84.0
+ provider registry.terraform.io/hashicorp/google-beta v4.84.0
+ provider registry.terraform.io/hashicorp/random v3.6.0
Affected Fastly Terraform Resource(s)
Please list the affected resources, for example:
fastly_service_vcl
Terraform Configuration Files
resource "fastly_service_vcl" "this" {
name = "test.examples.com"
domain {
name = "test.examples.com"
}
activate = true
stale_if_error = true
}
Expected Behavior
When first creating vcl service with:
stale_if_error = true
and change it to(and run apply):
stale_if_error = false
I would like the change to be applied to my fastly service
Actual Behavior
After changing it to stale_if_error = false and run terraform apply it outputs:
~ resource "fastly_service_vcl" "this" {
~ active_version = 2 -> (known after apply)
~ cloned_version = 2 -> (known after apply)
id = "xxxxxx"
name = "test.examples.com"
~ stale_if_error = true -> false
}
Plan: 0 to add, 1 to change, 0 to destroy.
But change is not applied to the service itself. I have to manually change it in the GUI to apply it
Debug Output (optional)
I can see the following in debug output
2024-02-26T15:17:58.697+0100 [WARN] Provider "provider[\"registry.terraform.io/fastly/fastly\"]" produced an unexpected new value for fastly_service_vcl.this, but we are tolerating it because it is using the legacy plugin SDK.
The following problems may be the cause of any confusing errors from downstream operations:
- .stale_if_error: was cty.False, but now cty.True
Steps to Reproduce
Please list the steps required to reproduce the issue, for example:
terraform applywithstale_if_error = true- Change
stale_if_error = false terraform apply
Thanks @rickardkarlsson for opening this issue. I've opened an internal ticket to track this and we'll update this GitHub issue when we have any feedback.