Missing Dependency Outputs Has Insufficiently Helpful Error Message

[yhakbar]

Describe the bug

When a unit depends on outputs from another unit with no dependencies, it throws an error that looks like the following:

08:57:09.936 ERROR  error occurred:

* ./foo/terragrunt.hcl is a dependency of ./bar/terragrunt.hcl but detected no outputs. Either the target module has not been applied yet, or the module has no outputs. If this is expected, set the skip_outputs flag to true on the dependency block.

08:57:09.936 ERROR  Unable to determine underlying exit code, so Terragrunt will exit with error code 1

While the error does accurately describe the problem, it doesn't offer the best prescriptive guidance on how to fix the issue.

Steps To Reproduce

Create the following fixture:

mkdir foo
mkdir bar
touch foo/main.tf
touch bar/main.tf
touch foo/terragrunt.hcl
touch bar/terragrunt.hcl

Then populate bar/terragrunt.hcl with the following:

dependency "foo" {
	config_path = "../foo"
}

Expected behavior

The error that Terragrunt could not determine the underlying exit code should be removed, as it's clear what the underlying error is, and there should be a hint that a user could have used mocks to avoid the issue if they encountered the error during a plan of a dependency that wasn't applied yet.

Ideally, there should actually be an HCL sample emitted that a user could copy + paste to bypass the issue.

Nice to haves

• Terminal output
• Screenshots

Versions

• Terragrunt version: v0.68.13
• OpenTofu version: v1.8.5
• Environment details (Ubuntu 20.04, Windows 10, etc.): MacOS

Additional context

I encountered this as an expected error while writing up a guide for new users to adopt Terragrunt. These are the most important errors to get right, and they should be as good as possible.

[wakeful]

hey,

Wouldn't emitting a suggestion about using a dependencies block instead be better and considered a best practice?

I'm happy to pick it up over the weekend!

[yhakbar]

I believe a user would still encounter an error if they used a dependencies block, right?

The crux of the issue is that most people use mocks in the scenario I outlined above because they want to be able to run-all plan in a new stack, and if there are dependencies in any unit of the new stack, they definitely won't be ready yet.

[wakeful]

Sorry, I should be more precise.

I agree that if the user is using outputs from other units in the inputs attribute, we should provide a suggestion to add the mock values, ideally with a fix based on the inputs they are trying to use. However, if there is no reference in the inputs, perhaps we should suggest using the dependencies block instead.

in your example if we would populate bar/terragrunt.hcl with

dependencies {
  paths = ["../foo"]
}

plan is passing without issues - that's why I mentioned that maybe, in cases where the end user is not passing anything to inputs, we should consider suggesting the other block as a best practice.

I'm just not sure if we can actually 'peek' that far into the parsing structure?

[yhakbar]

Ah, I see. I think there may be a case where seeing both recommended could be useful.

The guidance would be something like:

"""
If this dependency was accessed before the outputs were ready (which can happen during the plan of an unapplied stack), consider using mock_outputs.

e.g.

dependency "foo" {
    config_path = "../foo"

    mock_outputs = {
        foo_output = "mock-foo-output"
    }
}

You can learn more about this here:
https://terragrunt.gruntwork.io/docs/features/stacks/#unapplied-dependency-and-mock-outputs

If you do not need outputs from your dependency, consider using dependencies instead:
https://terragrunt.gruntwork.io/docs/reference/config-blocks-and-attributes/#dependencies
"""