Terraform apply says 0 to destroy but then plan errors with x already scheduled for deletion?

Terraform Providers AWS
1

My terraform plan yielded

Plan: 72 to add, 0 to change, 0 to destroy.

but then when I apply, I get 3 errors on like this

│ Error: creating Secrets Manager Secret: InvalidRequestException: You can’t create this secret because a secret with this name is already scheduled for deletion.

│ with module.ecs_backend[“orders_task”].module.backend_secrets.aws_secretsmanager_secret.sm[“devops-orders-env-secrets”],
│ on …/…/…/modules/aws/secrets_manager/main.tf line 1, in resource “aws_secretsmanager_secret” “sm”:
│ 1: resource “aws_secretsmanager_secret” “sm” {

I checked BEFORE I ran and the secret referred to does not exist. My ‘terraform show -json’ also does not contain this secret. Why is it saying it is scheduled for deletion when my plan shows 72 adds, 0 to destroy?

terraform version 1.4.6

looking at that terraform file, I see this

resource “aws_secretsmanager_secret” “sm” {
for_each = var.credentials

name = each.key

tags = {
Owner = “Terraform”
Environment = var.environment
}

lifecycle {
ignore_changes = [arn]
create_before_destroy = true
}
}

I did delete the secret from AWS and it is in a scheduled for deletion state but I was hoping terraform can bring it back here.

I then cancel deletion hoping it will sync but instead get the ‘resource already exists exception’. I look for attributes that will bring back cancellation or just revive and use existing secret but do not see anything on that either. (the secret is empty in tf and filled in by humans)

I see in docs the count = var.create_instance ? 1 : 0 but really want for this specific secrets to create if not exist (if scheduled for deletion, error is fine as we can revive manually and rerun). Anyway to do that perhaps as a best effort to create and manage?

2

Hi @deantray,

I’m not familiar enough with these AWS features to give a full answer but I did want to try to resolve an ambiguity I see in this error message:

This message is coming from the AWS provider rather than from Terraform itself, and the shape of the message suggests that the provider is just relaying verbatim a message returned from the underlying remote API.

Therefore this idea of “scheduled for deletion” is a concept of the remote API rather than of Terraform, and it’s independent of Terraform’s own action “destroy” as would be tallied in the plan summary you quoted. Terraform is not proposing to destroy anything here, but the remote API seems to have its own idea of planned or asynchronous deletion which is what this error is about.

I don’t know enough to say what it means for a secret to be “scheduled for deletion” in this AWS service, but I hope that the above is at least useful in separating Terraform’s own behavior from the remote API’s behavior, even though there’s some clashing terminology between the two here.