Ordering issue when deleting resources

[dmumpuu]

Provider version

tried with 8.3.2 and 8.4.0

Affected Fastly Terraform Resource(s)

• fastly_service_vcl
• fastly_domain_v1
• fastly_tls_subscription

Expected Behavior

Running terraform destroy or deleting these resources from the Terraform configuration should result in their removal from Fastly.

Actual Behavior

Errors:

Error: 400 - Bad Request:
Title:  Invalid value for subscriptions
Detail: This domain is linked to the following Fastly-managed TLS subscription(s): <subscription_id>. Remove the subscription(s) before deleting this domain.

Error: 400 - Bad Request:
Title:  Can't delete subscription
Detail: Subscription has active domains

Even if you try to remove them one-by-one using terraform destroy --target=fastly_tls_subscription.test and terraform destroy --target=fastly_domain_v1.test

Configuration example:

resource "fastly_domain_v1" "test" {
  fqdn       = "test.example.com"
  service_id = fastly_service_vcl.test.id
}

resource "fastly_tls_subscription" "test" {
  certificate_authority = "lets-encrypt"
  domains               = ["test.example.com"]
}

resource "fastly_service_vcl" "test" {
  name = "test"

  backend {
    name              = "fos-origin"
    address           = "eu-central.object.fastlystorage.app"
    override_host     = "eu-central.object.fastlystorage.app"
    ssl_cert_hostname = "eu-central.object.fastlystorage.app"
    ssl_sni_hostname  = "eu-central.object.fastlystorage.app"
    port              = 443
    use_ssl           = true
    ssl_check_cert    = true
  }

  force_destroy = true
}

[kpfleming]

Terraform does not know that the fastly_tls_subscription resource is dependent on the fastly_domain_v1 resource because there aren't any attributes set in the former to values from the latter. You could resolve this by manually creating a depends_on attribute to enforce the linkage, or you could set the domains attribute of the fastly_tls_subscription resource to [fastly_domain_v1.test.fqdn].

[dmumpuu]

Thanks for the suggestion! However, the issue here is not related to Terraform resource dependencies. Even if we add an explicit depends_on or set domains = [fastly_domain_v1.test.fqdn], the behavior will not change.

The root cause is the behavior of the Fastly API and the internal dependency implementation between tls_subscription and domain. The Fastly API returns a 400 error when attempting to delete either resource while the other still exists, and Terraform cannot work around that, even with correct dependency wiring.

In other words, this is not about Terraform ordering - I think, it's a limitation on Fastly’s side:

• you cannot delete a tls_subscription while the corresponding domain still exists
• you cannot delete a domain while a tls_subscription referencing it still exists

So even with explicit dependencies, Terraform will still fail on destroy, because the Fastly API rejects those operations.

[kpfleming]

Thanks for the additional information! If your analysis is correct, then this needs to be reported in a ticket our support team so that the Engineering team responsible for these API endpoints can address it.