Apply does not obey plan

[dwradcliffe]

I've been able to reproduce a situation where an apply action does not obey the saved plan. The console output never mentions the extra attribute it changed, but I have cloudtrail logs showing the change.

Situation:
I have an AWS instance, and I'm attempting to change the tags. My plan shows that the tag is the only change that will be performed:

~ aws_instance.my-instance.0
    tags.testing: "david" => "david1"

Plan: 0 to add, 1 to change, 0 to destroy.

I've saved the plan and ran apply using the saved plan:

aws_instance.my-instance.0: Modifying...
  tags.testing: "david" => "david1"
aws_instance.my-instance.0: Modifications complete

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

But now the instance has Source/dest. check set to True, where it was False before running apply.

I'm not sure if this is limited to this resource/attribute or if this is a bigger problem. Either way, it's a pretty big problem.

Note: This was brought to light via another bug with the source_dest_check attribute, but the fact remains, apply should obey the plan and correctly display the changes it is making.

@mitchellh @catsby @phinze @radeksimko

[thegedge]

Perhaps this is caused by the lack of ad.HasChange("source_dest_check") here?

[phinze]

Guessing this has something to do with the default being true for that field. Marked as a core bug and we'll definitely get this looked at before the next release for sure.

[mafonso]

Adding some more detail as I ran into this issue recently.
Turns out that this only shows when applying plan from Atlas terraform Terraform v0.6.4-dev (25bba596765417c65a6afb882a53b065b24ad882+CHANGES)
Both plan and apply mention source_dest_check: "" => "0" but in the end the eni is left with a value of true.
But when running plan with 0.6.3 against the same state afterwards it suggests a change
~ module.network.aws_instance.nat source_dest_check: "1" => "0" and an apply will actually make it to the eni.

[catsby]

Thanks for the additional information @mafonso – I believe this issue is resolved in the current master:

Terraform v0.6.4-dev (94db2fce3de658a1b902dc4dfebd8586c65ff28f+CHANGES)

I can't reproduce it as described. I believe the bug was introduced after v0.6.3 but fixed in this PR

• provider/aws: Fix issue with disabling source dest check on first run #3384

Sorry for the trouble. If you can still reproduce this on master please let me know.
Thanks!

[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.