terraform state mv panic

[RageYL]

Terraform Version

Terraform v0.12.24
+ provider.archive v1.3.0
+ provider.aws v2.69.0
+ provider.cloudflare v2.6.0
+ provider.local v1.4.0
+ provider.template v2.1.2

Updated to the current major version without success:

Terraform v0.12.28
+ provider.archive v1.3.0
+ provider.aws v2.69.0
+ provider.cloudflare v2.6.0
+ provider.local v1.4.0
+ provider.template v2.1.2

Terraform Configuration Files

crash.log

Steps to Reproduce

I first moved a map of zones to a non existent resource:

terraform state mv 'cloudflare_zone.zones' 'module.cloudflare.cloudflare_zone.zones'

Then I tried to correct the mistake I made and terraform panics.

terraform state mv 'module.cloudflare.cloudflare_zone.zones' 'module.cloudflare.cloudflare_zone.this'

[alisdair]

Thanks for reporting this! I've been unable to reproduce the panic, and from looking at the stack trace it's not immediately obvious what the problem is. Could you help us try to find a reduced reproduction configuration?

Here's what I tried (with Terraform 0.12.28 and Terraform 0.13.0-beta3):

1. Create trivial config with one resource, run terraform init and terraform apply. Here's main.tf:

   resource "null_resource" "foo" {}

2. Move this configuration to a module, ./modules/nulls/main.tf, and call it from the root configuration (then run terraform init):

   module "nulls" {
     source = "./modules/nulls"
   }

3. Move the resource to a non-existent address in the module:

   $ terraform-0.12.28 state mv null_resource.foo module.nulls.null_resource.bar
   Move "null_resource.foo" to "module.nulls.null_resource.bar"
   Successfully moved 1 object(s).

4. Move the resource to the correct address:

   $ terraform-0.12.28 state mv module.nulls.null_resource.bar module.nulls.null_resource.foo
   Move "module.nulls.null_resource.bar" to "module.nulls.null_resource.foo"
   Successfully moved 1 object(s).

Unless I'm missing something, this seems identical to what you reported (just using a simpler provider), so it should reproduce the bug. Can you see any differences? Are you able to reproduce the bug yourself?

[RageYL]

I was able to reproduce:

1. Create a map of resources:

locals {
  items = toset(["A", "B", "C"])
}

resource "null_resource" "foo" {
  for_each = local.items
}

2. Move this configuration to a module

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

3. Move the resources to a non-existent address in the module:

$ terraform state mv null_resource.foo module.bug.null_resource.bar
Acquiring state lock. This may take a few moments...
Move "null_resource.foo" to "module.bug.null_resource.bar"
Successfully moved 1 object(s).
Releasing state lock. This may take a few moments...  

4. Move the resources to the correct address:

$ terraform state mv  module.bug.null_resource.bar module.bug.null_resource.foo
Acquiring state lock. This may take a few moments...
Move "module.bug.null_resource.bar" to "module.bug.null_resource.foo"
Releasing state lock. This may take a few moments...
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x18 pc=0x197b964]
...

This should let you reproduce the bug.

[alisdair]

That's great, thanks @RageYL!

[alisdair]

There's a fix for this bug in #25523. Thanks again for the repro!

If your state file is in a bad spot, you can work around the bug by individually moving each counted instance. For the example above, this little bash script should do the job:

for src in $(terraform state list module.bug.null_resource.bar)
do
  terraform state mv $src "${src/bar/foo}"
done

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.