[Bug]: aws_lambda_function version attribute always changing

[shaked-seal]

Terraform Core Version

1.5.7

AWS Provider Version

5.21.0

Affected Resource(s)

We are running terraform apply, and we see the following:

Terraform will perform the following actions:

  # module.lambda.aws_lambda_alias.alias[0] will be updated in-place
  ~ resource "aws_lambda_alias" "alias" {
      ~ function_version = "102" -> (known after apply)
        id               = "arn:aws:lambda:region:account:function:lambda_name:alias"
        name             = "alias"
        # (4 unchanged attributes hidden)
    }

  # module.lambda.aws_lambda_function.function will be updated in-place
  ~ resource "aws_lambda_function" "function" {
        id                             = "lambda-name"
        tags                           = {
            "env"                   = "env"
            "workspace"             = "worspace"
        }
      ~ version                        = "102" -> (known after apply)
        # (25 unchanged attributes hidden)

        # (4 unchanged blocks hidden)
    }

  # module.lambda.aws_lambda_provisioned_concurrency_config.function[0] must be replaced
-/+ resource "aws_lambda_provisioned_concurrency_config" "function" {
      ~ id                                = "lambda-name,102" -> (known after apply)
      ~ qualifier                         = "102" # forces replacement -> (known after apply) # forces replacement
        # (3 unchanged attributes hidden)
    }

Plan: 1 to add, 2 to change, 1 to destroy.

Expected Behavior

We would like to see no changes in the Terraform plan when there are no changes to the terraform or s3 object.
From the plan result, it seems that the only change is the version of the aws_lambda_function.

We added:

  lifecycle {
    ignore_changes = [
      # https://github.com/hashicorp/terraform-provider-aws/issues/29085
      last_modified,
      qualified_arn,
      qualified_invoke_arn,
    ]
  }

But still, we have the version updated.

Actual Behavior

No changes in plan if there are no terraform or s3 object change.

Relevant Error/Panic Output Snippet

We believe this is only relevant with the lambda signature feature.

### Terraform Configuration Files

data "aws_s3_object" "main" {
  bucket = "name"
  key    = "key"
}

resource "aws_signer_signing_job" "main" {
  profile_name = "name"
  source {
    s3 {
      bucket  = "name"
      key     = "key"
      version = data.aws_s3_object.main.version_id
    }
  }
  destination {
    s3 {
      bucket = "name"
      prefix = "signed/"
    }
  }
}

data "aws_s3_object" "signed" {
  bucket = "name"
  key    = aws_signer_signing_job.main.signed_object[0]["s3"][0]["key"]
}


resource "aws_lambda_function" "function" {
  function_name                  = "name"
  s3_bucket                      = "name"
  s3_key                         = aws_signer_signing_job.main.signed_object[0]["s3"][0]["key"]
  source_code_hash               = data.aws_s3_object.signed[0].checksum_sha256
  publish = true
  code_signing_config_arn = "arn"
  ...

  lifecycle {
    ignore_changes = [
      # https://github.com/hashicorp/terraform-provider-aws/issues/29085
      last_modified,
      qualified_arn,
      qualified_invoke_arn,
    ]
  }
}

Steps to Reproduce

Use the code above with lambda signature.

Debug Output

Debug log did not show why the version is updated

Panic Output

No response

Important Factoids

No response

References

No response

Would you like to implement a fix?

None

[github-actions]

Community Note

Voting for Prioritization

• Please vote on this issue by adding a 👍 reaction to the original post to help the community and maintainers prioritize this request.
• Please see our prioritization guide for information on how we prioritize.
• Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request.

Volunteering to Work on This Issue

• If you are interested in working on this issue, please leave a comment.
• If this would be your first contribution, please review the contribution guide.

[xnick123]

Hi, I was struggling with this too and experimented last week.

I am sure this is not a bug.

There are probably various ways to get it right, I’ll show my approach. The "what to do" became clear, even though it was obvious in the proven implementation of Anton Babenko’s lambda module https://github.com/terraform-aws-modules/terraform-aws-lambda/tree/v7.2.2/examples/code-signing But that didn't help me in the beginning.

You need to remove source_code_hash from your lambda. Your intention is totally right, and I was doing the same.

Make use of the source_hash in the s3 object resource (see below) of the unsigned object, which will trigger a new signing job, whenever it is not matching the previous hash. The signing job will create a new signed zip file (which looks like, this pattern 87336-27636-266462-27726.zip). Because the key changes (on change of the source file's hash), your lambda function will be updated with the new zip package and a new version is created. No need to add more - as the goal is achieved. If the source hash is the same, no signing job will be created, hence no version change.

resource "aws_s3_object" "lambda_artifacts" {
  for_each    = local.lambda_zip
  bucket      = module.lambda_artifacts.s3_bucket_id
  key         = "${each.value}.zip"
  source      = "${each.value}.zip"
  source_hash = filebase64sha256("${each.value}.zip")
}

If I remember right data.aws_s3_object.signed[0].checksum_sha256 is empty. The signer job is not populating/activating this to be filled. Check its value with an output resource, this helped me.

As a general note, I didn’t know that: The checksum-sha256 is not necessarily a guarantee that it will contain the sha256 of the uploaded file, as for multipart uploads it is calculated differently.. As per https://docs.aws.amazon.com/AmazonS3/latest/userguide/checking-object-integrity.html larger files (>=16mb are uploaded as multipart, I am sure there are variations). If you see the checksum having a dash number at the end e.g. -7 you know that the file was uploaded as 7 multipart objects. Which happened when I tried to make use of that.

Concerning the “lifecycle ignore” changes part, this confuses many. In this case at least the “last modified” is ignored if 8 remember right, at least not a cause of triggering a new version to be created. I didn’t lookup that part up for this comment. But I would remove it, and it didn't make a difference either.

Closing, I think this - data "aws_s3_object" "signed" - can be removed. For the unsigned s3 object I see a data resource in the code example, but I’d focus on the resource as such and if this is right, the data resource for unsigned can be used too of course.

Let me know if I got something wrong.

[justinretzolk]

The above is similar to explanations I've seen elsewhere in similar threads. With that in mind, since there's nothing for the team to do in this case, closing.

[github-actions]

Warning

This issue has been closed, meaning that any additional comments are hard for our team to see. Please assume that the maintainers will not see them.

Ongoing conversations amongst community members are welcome, however, the issue will be locked after 30 days. Moving conversations to another venue, such as the AWS Provider forum, is recommended. If you have additional concerns, please open a new issue, referencing this one where needed.

[github-actions]

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.