Possible bug with implicit moved blocks?

An interesting one @apparentlymart we’ve just seen (latest Terraform version), which I’m not sure if it is a bug or just doing something wrong:

We have a module that recently had a change to add some optional resources (by adding count = var.xxx ? 1 : 0. This is a module stored in a separate git repo.

That module is then used within another module (another repo) and finally within a root module (third repo).

Running plan then gave us a set of errors about moved blocks not being allowed cross-repo. There are no explicit moved blocks, so I think it is the implicit ones that Terraform creates for the adding/removing count use case. However I’m not sure why it is giving the error? By any chance does it “put” the implicit moved blocks within the root module code, rather than “next to” the code which has changed?

1 Like

Hi @stuart-c,

Can you try with the latest v1.1.3? There were a number of bug fixes that could relate to nested moves.


This was with 1.1.3 already

Thanks. It’s obviously a problem with the implicit moves here, but no idea what exactly is causing it. If you can add a minimal example I’ll take a look, otherwise I’ll try to see if I can repro it here too.

I would also be interested to see a reproduction case if you have one, but I can also imagine how this might occur and so we can maybe construct a reproduction case ourselves, if we can confirm this to be true:

When Terraform infers implied move blocks it currently treats them as if they were moved blocks written in the root module, because that’s then allows these implied statements to refer to resources in specific instances of child modules because not all instances of a module will necessarily need the same implied move statements, depending on the prior state.

It sounds like Terraform might be incorrectly including those implied statements when it does the cross-package move validation, and thus generating an error if there’s a module package boundary anywhere in the module path of the address.

Fortunately we do internally track whether each move statement was implied exactly so that we can make exceptions like this when needed, so if I’m right about the root cause here it should at least not be a big ordeal to fix it. :crossed_fingers:

Looking a bit deeper in the code just before I finish work for the week, it does look like there’s a missing exception for implied move statements in the validation code:

@stuart-c would you mind opening a GitHub issue for this, so we can make sure this is visible to the whole engineering team? (Not everyone monitors this forum closely.) If you have one it’d be helpful to include a reproduction case we can test against, but I do understand that it’s often hard to produce a minimal reproduction case for a situation involving external modules. In the absence of a reproduction case, including a full exact error message would at least help show the “bones” of your situation so that we can try to craft a regression test case that matches it as closely as possible.

I hit this today, too. Updating a git::https module source that had a resource add a ternary count .

In the interests of creating the reverse link, here’s the issue where we’re now tracking this bug:

Hi, I am getting the same issue and I just saw that you merge a pr to fix it, could you tell me please when this change will be available on a release? It’s blocking me :frowning: I have been asked on my job to do some upgrades on a project, but I got this error.

You can do a manual terraform state mv in the meantime.

Thank you for your recommendation Stuart. I am going to check it, the issue that is causing me curiosity is where I am going to move it? because my tree and the path in the module are the same, I saw other comments saying the same but it’s not clear to me.

So for example you might have changed a resource to add a count, which renames the resource to add [xxx] to the name. So in the case where you are adding a count to change a resource to only be conditionally created you might have


Terraform should altomatically handle that renaming, but the bug is preventing that. So to manually fix you would run terraform state mv module.xxx.aws_resource.name module.xxx.aws_resource.name[0]

Thanks for this @stuart-c! Your last comment solved the issue I was having after adding a count argument and ternary.