Destroy doesn't respect module dependencies correctly

[lamdor]

I've ran into an issue similar to #1472 and I think i've distilled it to a simple example.

This is on the current master of terraform:

$ terraform version
Terraform v0.5.0-dev (d9e8c112aec46ff62805833ced449364e3115290)

Given a configuration:

./main.tf

module "a_module" {
  source = "./a_module"
}

resource "null_resource" "b" {
  blah = "${module.a_module.a_output}"
}

./a_module/main.tf

resource "null_resource" "a" {
}

output "a_output" {
  value = "${null_resource.a.id}"
}

On apply, it should bring up a_module.null_resource.a before it brings up root.null_resource.b and on destroy, it should destroy b before a by respecting the dependency.

So on apply I get:

$ terraform apply
module.a_module.null_resource.a: Creating...
module.a_module.null_resource.a: Creation complete
null_resource.b: Creating...
null_resource.b: Creation complete

Apply complete! Resources: 2 added, 0 changed, 0 destroyed.

The state of your infrastructure has been saved to the path
below. This state is required to modify and destroy your
infrastructure, so keep it safe. To inspect the complete state
use the `terraform show` command.

State path: terraform.tfstate

Good there..

In the terraform.tfstate, I have:

{
    "version": 1,
    "serial": 1,
    "modules": [
        {
            "path": [
                "root"
            ],
            "outputs": {},
            "resources": {
                "null_resource.b": {
                    "type": "null_resource",
                    "depends_on": [
                        "module.a_module"
                    ],
                    "primary": {
                        "id": "4686510281091019717",
                        "attributes": {
                            "id": "4686510281091019717"
                        }
                    }
                }
            }
        },
        {
            "path": [
                "root",
                "a_module"
            ],
            "outputs": {
                "a_output": "7727900350613538303"
            },
            "resources": {
                "null_resource.a": {
                    "type": "null_resource",
                    "primary": {
                        "id": "7727900350613538303",
                        "attributes": {
                            "id": "7727900350613538303"
                        }
                    }
                }
            }
        }
    ]
}

But when I destroy:

$ terraform destroy -force
module.a_module.null_resource.a: Refreshing state... (ID: 7727900350613538303)
null_resource.b: Refreshing state... (ID: 4686510281091019717)
null_resource.a: Destroying...
null_resource.a: Destruction complete
null_resource.b: Destroying...
null_resource.b: Destruction complete

Apply complete! Resources: 0 added, 0 changed, 2 destroyed.

It's destroying a before b, which I wouldn't expect. This has led to problems in which a module that we depend on creates something which we add to it in our own config. But when we destroy, the service behind the "parent" blows up because it's not empty. If destroyed the leaves first, it wouldn't have this problem.

[lamdor]

This might be a dupe of #922

[phinze]

Thanks for putting the work in to provide us with a detailed example, @rubbish - this will help us a lot with the debugging process. Tagged and we'll take a look.

[mitchellh]

I think this is another example where we need to expand modules out in the same graph and this would just get fixed.

[bitglue]

I run into blocking problems every time I try to do something non-trivial with Terraform due to module-related bugs with dependencies and interpolation, both on destroy and create. If you need any more examples of problematic configurations, I have a lot.

[mitchellh]

This is fixed now in my branch. I'll PR soon.

[ghost]

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.