Updating to 0.38.1 from 0.37.1 breaks terragrunt-cache source update

[targeter21]

Hi, on MacOS I updated to the latest version of Terragrunt and found it no longer updates the cache folder when I make changes to my Terraform source. When I make a change to the Terraform code, no plan changes are detected because the cache directory has the old version of the code. Previously that wasn't the case and worked as expected.

[lorengordon]

I think I'm seeing this also, or something similar. I just updated to terragrunt 0.38.2 this morning, and now even running terragrunt init does not actually update the terragrunt cache, even though the source in terragrunt.hcl is pointing to a local module that has changed. This was working fine in 0.37.1. Now, I have to use --terragrunt-source-update to force the cache to update.

[lorengordon]

I've tested 0.37.1, 0.37.2, and 0.37.3, and it stops working in 0.37.3, which seems to confirm that the change in PR #2006 introduced the problem.

[denis256]

Hi,
I was also looking into this issue, can you share an example code that reproduce this issue

[lorengordon]

My main repo is really quite complicated. Not sure I can exactly distill it down for a repro. But the general setup is something like:

├── configs
│   └── aws
│       ├── <account_id>
│       │   └── base
│       │       └── terragrunt.hcl
│       └── terragrunt.hcl
├── roots
│   └── base
│       ├── main.tf
│       ├── outputs.tf
│       ├── variables.tf
│       └── versions.tf

and the terragrunt.hcl is super simple:

# Include all settings from the root terragrunt config
include {
  path = find_in_parent_folders()
}

terraform {
  source = "../../../..//roots/base"
}

And then I make a change to the roots/base module, say adding a new module block, or changing the git version ref of an existing module.

Then I run terragrunt init --terragrunt-working-dir configs/aws/<account_id>/base. If I have a pre-existing copy in my terragrunt cache, in 0.37.3, the cache is not updated and the init does not pick up the change. Prior to 0.37.3, this works fine.

[denis256]

I put together a small test https://github.com/denis256/terragrunt-tests/tree/master/issue-2171

├── README.md
├── app
│   └── mod1
│       └── terragrunt.hcl
├── modules
│   ├── mod1
│   │   └── main.tf
│   └── mod2
│       └── terragrunt.hcl
└── terragrunt.hcl

I tried to update app/mod1, modules/mod1, modules/mod2 but still .terragrunt-cache is refreshed with changes...

(tested on Ubuntu 22.04 LTS)

It is a similar setup that generates the issue?

[lorengordon]

That setup looks like it represents what I described, but when I test your repo, I also cannot reproduce the issue. There must be something in the cache refresh step that interacts with other terragrunt features that we're using? We're also using remote_state, extra_arguments, before_hook, after_hook, generate, inputs, and locals.

[lorengordon]

Or mebbe... looking over the changeset for #2006, mebbe for some other reason I'm hitting a hash error in this project when calculating the hash for the source directory, and so it's just returning the hash of the source url (which hasn't changed)?

• v0.37.2...v0.37.3#diff-236a2a82d4

If so, could we at least get some more debug logging in there, that doesn't just swallow the error?

[denis256]

In https://github.com/denis256/terragrunt-tests/releases/tag/issue-2171 I added a build that will log errors, I will also try scenario when error happens during hash calculation

[lorengordon]

Yep, the hash function is hitting an error!

INFO[0001] Failed to get source version: read /home/loren/git/repos/iac-project/modules/cds_pack/tests/main_cds_pack/.terraform/providers/registry.terraform.io/hashicorp/aws/3.51.0/linux_amd64: is a directory
DEBU[0001] Terraform files in /home/loren/.terragrunt-cache/WpO4iwyH03ifWYsxY6z23lLU8Pc/WVS7GWboD6atBoxbAb1lGamic0Y/roots/base are up to date. Will not download again.

[denis256]

Hi,
it is possible to retest with Terragunt v0.38.4 to see if the issue was fixed?

https://github.com/gruntwork-io/terragrunt/releases/tag/v0.38.4

[targeter21]

I can, though it looks like 0.38.4 isn't available on Brew yet, only 0.38.3. Is that going to change soon? Greatly appreciate the work and activity on this issue btw :)

[lorengordon]

Using 0.38.4, I am no longer seeing the behavior I was describing earlier. It is now working as expected! Thanks!

However I was expecting to see a warning about the failure to hash the directory, but I am not seeing that either. Perhaps the new hash approach in 0.38.4 is not susceptible in the first place to the failure mode I was encountering in the prior hash approach?

[denis256]

Hi,
I think since hashing calculation is based on files metadata it may not generate file reading errors