fix: Fix error with inconsistent values for fileexists when setting the source code hash

[flora-five]

Description

Ensure that the local package has been created before computing its hash by using a terraform_data resource that depends on null_resource.archive. fileexists is not used anymore, integrating the change from #728.

Other changes:

• removes the code for was_missing from package.py because it is not used anymore
• outputs the value of code_sha256 attribute for functions and layers, outputs the value of source_code_hash attribute for layers
• replace the deprecated null_data_source in the example code for creating a function from a downloaded package

Motivation and Context

The source_code_hash was obtained with an expression that used the fileexists and filebase64sha256 functions and, because the package file may have not been created yet, their values changed between plan and apply. In newer Terraform versions those functions must not change their result between plan and apply. The apply failed with an error about inconsistent values returned by the functions.

Fixes #727
Fixes #733
Closes #728

Breaking Changes

No

How Has This Been Tested?

• I have updated at least one of the examples/* to demonstrate and validate my change(s)
• I have tested and validated these changes using one or more of the provided examples/* projects
• I have executed pre-commit run -a on my pull request

[lorengordon]

This appears to implement option (4) from my proposal in this message thread: #727 (comment). Seems pretty reasonable to me.

[anioool]

This PR cause some logic is gone , ie. You cannot pass already created package by other terraform resource and made the decision about deployment based on calculated source_code_hash.

[flora-five]

You are right, thanks for catching that! I will work to improve.

[lorengordon]

That would be option (2) from my proposal. :)

2. User builds package and provides source code hash

Idea being to add an output for data.external.archive_prepare[0].result.content_hash, and also an input that accepts source_code_hash.

[flora-five]

@lorengordon and @anioool I have replaced completely the initial version with a better option that doesn't require the users of the module to make changes to their code. I would appreciate if you would take a look too, thanks!

[lorengordon]

@flora-five Intriguing! I'll try to run it through a few of my use cases as soon as I get a chance. Probably Thursday.

[lorengordon]

@flora-five First issue I see is a diff after apply, when the builds/ directory is not present after the initial apply. To reproduce:

1. Set ignore_source_code_hash = true and recreate_missing_package = false, and apply a config that creates the package and deploys the lambda.
2. Run a plan to see there is no drift.
3. Delete the builds/ directory to simulate a new system.
4. Run the plan again to see something similar to:

Terraform will perform the following actions:

  # module.test_create_function.module.lambda.aws_lambda_function.this[0] will be updated in-place
  ~ resource "aws_lambda_function" "this" {
        id                             = "new-account-support-case-320CLIzt"
      + source_code_hash               = (known after apply)
        tags                           = {}
        # (31 unchanged attributes hidden)

        # (4 unchanged blocks hidden)
    }

  # module.test_create_function.module.lambda.terraform_data.source_code_hash will be updated in-place
  ~ resource "terraform_data" "source_code_hash" {
        id               = "541b3f48-15af-624a-8f85-d530f9723ea5"
      ~ output           = {
          - base64sha256 = null
          - filename     = "./builds/83716c2c1e76bf7a951eb863f0f568b36f2cb7ee8b73ee622fabb387c10bbbcf.zip"
        } -> (known after apply)
        # (2 unchanged attributes hidden)
    }

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

[lorengordon]

Also, here is a scenario that generates a diff after apply, that also fails on second apply... To reproduce:

1. Set ignore_source_code_hash = false and recreate_missing_package = false, and apply a config that creates the package and deploys the lambda.
2. Run a plan to see there is no drift.
3. Delete the builds/ directory to simulate a new system.
4. Run apply again to see a similar diff and failure to apply:

Terraform will perform the following actions:

  # module.test_create_function.module.lambda.aws_lambda_function.this[0] will be updated in-place
  ~ resource "aws_lambda_function" "this" {
        id                             = "new-account-support-case-kocqYK9o"
      ~ last_modified                  = "2026-02-11T19:35:34.461+0000" -> (known after apply)
      ~ source_code_hash               = "PGrK9TuZ+cOHnoBO9t7Uxpuf/dLRJrUdvETZ3qfHoFQ=" -> (known after apply)
        tags                           = {}
        # (30 unchanged attributes hidden)

        # (4 unchanged blocks hidden)
    }

  # module.test_create_function.module.lambda.terraform_data.source_code_hash will be updated in-place
  ~ resource "terraform_data" "source_code_hash" {
        id               = "f3749523-629a-df2b-f34f-593a027074a3"
      ~ input            = {
          ~ base64sha256 = "PGrK9TuZ+cOHnoBO9t7Uxpuf/dLRJrUdvETZ3qfHoFQ=" -> null
            # (1 unchanged attribute hidden)
        }
      ~ output           = {
          - base64sha256 = "PGrK9TuZ+cOHnoBO9t7Uxpuf/dLRJrUdvETZ3qfHoFQ="
          - filename     = "./builds/83716c2c1e76bf7a951eb863f0f568b36f2cb7ee8b73ee622fabb387c10bbbcf.zip"
        } -> (known after apply)
        # (1 unchanged attribute hidden)
    }

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

Do you want to perform these actions?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.

  Enter a value: yes

module.test_create_function.module.lambda.terraform_data.source_code_hash: Modifying... [id=f3749523-629a-df2b-f34f-593a027074a3]
module.test_create_function.module.lambda.terraform_data.source_code_hash: Modifications complete after 0s [id=f3749523-629a-df2b-f34f-593a027074a3]
╷
│ Error: Resource postcondition failed
│
│   on .terraform/modules/test_create_function.lambda/package.tf line 96, in resource "terraform_data" "source_code_hash":
│   96:       condition     = var.ignore_source_code_hash || self.output.filename == null ? true : fileexists(self.output.filename) && self.output.base64sha256 != null
│     ├────────────────
│     │ self.output.base64sha256 is null
│     │ self.output.filename is "./builds/83716c2c1e76bf7a951eb863f0f568b36f2cb7ee8b73ee622fabb387c10bbbcf.zip"
│     │ var.ignore_source_code_hash is false
│
│ Hash of package file ./builds/83716c2c1e76bf7a951eb863f0f568b36f2cb7ee8b73ee622fabb387c10bbbcf.zip must be not null, does the file exist?

[lorengordon]

Also a bit odd workflow for one more scenario:

1. Set ignore_source_code_hash = true and recreate_missing_package = true. Apply a config that creates the package and deploys the lambda.
2. Run a plan to see there is no drift.
3. Delete the builds/ directory to simulate a new system.
4. Run apply again, and note that it still wants to update the lambda with an "unknown" source_code_hash, but it shouldn't because that should be known always as null because ignore_source_code_hash = true:

  # module.test_create_all.module.lambda.aws_lambda_function.this[0] will be updated in-place
  ~ resource "aws_lambda_function" "this" {
        id                             = "new-account-support-case-Do8RPCGx"
      + source_code_hash               = (known after apply)
        tags                           = {}
        # (31 unchanged attributes hidden)

        # (4 unchanged blocks hidden)
    }

[flora-five]

Thank you @lorengordon for the checks! Indeed, the resource added to obtain the hash caused more diffs.

I have been able to simplify the code to work as before for your test cases.

[flora-five]

I've added a small optimization to avoid the creation of the resource used for calculating the zip archive hash if changes to source code hash should be ignored.

[lorengordon]

@flora-five Nicely done... Ok, I tested all my scenarios again and it appears to be working.

@antonbabenko I think this is good to go, whenever you have a chance to review.

[antonbabenko]

👍 👍 👍

[antonbabenko]

This PR is included in version 8.5.1 🎉