output_base64sha256 often returns the hash of an empty file instead of the hash of the contents

[hashicorp]

output_base64sha256 often returns the hash of an empty file instead of the hash of the contents

[pauldraper]

Perhaps because each module instance is recreating the zip and a race condition is causing the hash to be generated when the zip hasn't finished being filled?

Correct.

[pauldraper]

Do you have multiple instances of this archive_file (like multiple instance of its module)?

If so, I suspect Terraform is recreating and hashing the file in parallel, leading to inconsistent results.

Workarounds:

• Pass a unique parameter and use that in the output path of the archive_file
• Create the archive once for entire workspace (singleton module), and then pass that value into the module that creates the Lambda function.

[pauldraper]

Though archive_file is problematic for other reasons as well, like being platform specific.

#34

[chrisbloe]

I have also had this problem for a long time... I tried both options on #34 but still saw the problem.

In my case, the zip is being created within a module, so the file should absolutely be identical for each instance of the module, however, the plan shows different hashes for the same file being used across the modules! Perhaps because each module instance is recreating the zip and a race condition is causing the hash to be generated when the zip hasn't finished being filled?

So, I just tried to change my code from...

resource "aws_lambda_function" "my_function" {
  ...
  source_code_hash = data.archive_file.my_zip.output_base64sha256
}

...to...

resource "aws_lambda_function" "my_function" {
  ...
  source_code_hash = filebase64sha256("${path.module}/files/my_file.zip")
}

...to calculate the hash directly, and, running the plan a few times seems to consistently show the correct hash value... so I think I'll change all mine over for now... and I think it would be worth updating the documentation here to suggest the output may not be consistent.

Note: The suggested output_file_mode fix in #34 may or may not have helped, I'm not sure!