aws_lambda_function does not use partial state and will update the "filename" property even when it can't be read.

[bellis-ai]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• 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
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Terraform CLI and Terraform AWS Provider Version

AWS v.4.22.0

Affected Resource(s)

aws_lambda_function

Terraform Configuration Files

First apply this

resource "aws_iam_role" "iam_for_lambda" {
  name = "iam_for_lambda"
  assume_role_policy = <<EOF
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Action": "sts:AssumeRole",
      "Principal": {
        "Service": "lambda.amazonaws.com"
      },
      "Effect": "Allow",
      "Sid": ""
    }
  ]
}
EOF
}


resource "aws_lambda_function" "test_lambda" {
  filename      = "lambda_function_payload.zip"
  function_name = "lambda_function_name"
  role          = aws_iam_role.iam_for_lambda.arn
  handler       = "index.test"
  runtime = "nodejs12.x"
}

Then change filename to a nonexistent file:

resource "aws_lambda_function" "test_lambda" {
  filename      = "nonexistent.zip"
  function_name = "lambda_function_name"
  role          = aws_iam_role.iam_for_lambda.arn
  handler       = "index.test"
  runtime = "nodejs12.x"
}

Output:

unable to load "nonexistent.zip": open nonexistent.zip: no such file or directory

at first, but if you apply again, it goes through

No changes. Your infrastructure matches the configuration.

Expected Behavior

Upon failure, filename isn't updated

Actual Behavior

Filename is updated

Steps to Reproduce

1. terraform apply a proper lambda function
2. Change the filename to a nonexistent file
3. terraform apply again and fail.
4. terraform apply again and you will succeed?!

Important Factoids

Look around this line of the provider. No partial state is implemented in regards to updating filename:

terraform-provider-aws/internal/service/lambda/function.go

Line 1221 in d4c9e27

return fmt.Errorf("unable to load %q: %w", v.(string), err)

Loock at the docs of the Terraform Custom Providers Page:

If the Update callback returns with or without an error, the full state is saved. If the ID becomes blank, the resource is destroyed (even within an update, though this shouldn't happen except in error scenarios).

The aws_lambda_function does not implement partial state in regards to updating fields that don't exist on AWS like "filename". Because of this, failure to read in a file will still save the updated filename in the diff. This is definitely not desired behavior and exacerbates problems lambda implementations such as the aws lambda module.

[miyajan]

I ran into the similar problem with the s3_key property.

1. terraform apply a proper lambda function
2. Change the s3_key to a nonexistent key
3. terraform apply again and fail
4. terraform apply shows No changes. and the state of the lambda function has the nonexistent s3_key

AWS provider version: v4.30.0

[ewbankkit]

The root cause of this issue is described in hashicorp/terraform-plugin-sdk#476.
No matter if a resource's Update handler succeeds or fails, the Terraform state value that is persisted is the proposed new state.
As neither filename, s3_bucket or s3_key is returned from any AWS Lambda API call, a subsequent terraform refresh (which also happens implicitly during terraform apply) cannot discover the actual values and the state will continue to contain the value(s) which caused the update to fail.
What we can do is, if the UpdateFunctionCode API fails, set the proposed new values for filename, s3_bucket and s3_key to their previous values. These previous values will then be persisted in place of the new values.

[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.