terraform plan crash

[noah10]

Terraform Version

Terraform v1.6.6
on darwin_arm64
+ provider registry.terraform.io/hashicorp/aws v5.31.0

Terraform Configuration Files

terraform {
  backend "s3" {
    bucket = "some-state-bucket"
    region = "us-west-2"
    key = "cognito"
    workspace_key_prefix = "workspaces"
  }
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.31"
    }
  }
}

provider "aws" {
    region = var.region
}

# This is created as part of the serverless deployment
data "aws_ssm_parameter" "post-confirmation-lambda-arn" {
  name = "/${var.project}/${var.env}/info/lambdas/write-user-on-verify/arn"
}

data "aws_ssm_parameter" "cognito-user-pool-id" {
  name = "/${var.project}/${var.env}/info/cognito/user-pool/id"
}

import {
  to = aws_cognito_user_pool.pool
  id = data.aws_ssm_parameter.cognito-user-pool-id.value
}

resource "aws_cognito_user_pool" "pool" {
    name = "${var.project}-${var.env}-users"

   lambda_config {
      post_confirmation = data.aws_ssm_parameter.post-confirmation-lambda-arn.value
    }
}

Debug Output

https://gist.github.com/noah10/ebe566e6b8d19a7f240a99d2ea35279e

Expected Behavior

No crash

Actual Behavior

Crash

Steps to Reproduce

Unfortunately I can reproduce this reliably by doing terraform plan. I suspect that it may not be reproducible without my state file, though.

Additional Context

I have an unusual setup that's a mix of terraform and serverless. I create all of my terraform resources, then deploy my serverless resources. One of those resources is a lambda script used by an aws cognito user pool created in the first terraform deployment, so after deploying my serverless resources I then do another terraform deployment that modifies a that user pool resource to attach the lambda script. The terraform config above is for this second deployment.

References

No response

[noah10]

I just narrowed it down to the import block - commenting that out results in the expected output for terraform plan.

[liamcervante]

Hi @noah10, thanks for filing this!

Hopefully the id value you've chosen to pass into import block is marked as sensitive? If so, I've been able to replicate this. I've marked the issue as confirmed. The stack trace I get matches your stack trace as well, so I think it is the same issue. Essentially, Terraform can't process sensitive values without explicitly removing the sensitive metadata first. The bug is in the import block which isn't unmarking the value before it tries to process it and so we see the crash that you've found.

Here is a smaller example that is easier to execute for reproduction (doesn't use any resources that require provider configurations):

# main.tf
resource "tfcoremock_simple_resource" "resource" {
  id = var.id
}

variable "id" {
  default   = "my-value"
  type      = string
  sensitive = true
}

import {
  to = tfcoremock_simple_resource.resource
  id = var.id
}

If the variable is marked as sensitive we get the crash, if not then we get an expected error about the resource not existing which is fine.

[liamcervante]

After my long comment, it looks this was already fixed by https://github.com/hashicorp/terraform/pull/33932.

@noah10, the fix is available in the latest 1.7 series release candidate (1.7.0-rc1) and will be made fully available in the upcoming 1.7.0 release later this month.

With that in mind, I'll close the issue. Thanks again for filing it!

[github-actions[bot]]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.