Thanks, well take a look at reproducing this. There must be something really strange here because the create/update graph is identical: we build logical graphs that don't depend on the operation. The walk order should be the same. But I'll take a look.

I'm having trouble reproducing this. I wrote a couple test cases really quickly here and I'm seeing good behavior all around. The test cases I have (that work properly):

• Basic graph test that dependency order happens even if they exist: ordering is honored
• Computed attribute change while there is already state: compute is trickled down to the update
• Computed attribute change during refresh: trickles down to the update

Can you get me a minimal example that has the full normal steps of:

1. No state
2. Plan
3. Apply (result: state)
4. Config change
5. Plan
6. Apply

And logs for all of those? I can't continue without it since its not obvious to me. Thanks!

@mitchellh just narrowed some stuff down with @phinze and did more testing and it appears that this only happens when the computed value is updated in Update. If the value is updated in Read, everything behaves normally.

As a corollary this means it can only be tested by ensuring that the value is only updated in Update.

@jefferai I think this comes back to: does the plan say it is going to be updated? The plan must reflect that the update will happen.

On the first run, no.

If I change some (non-computed) value in Resource A, terraform plan says that Resource A will be updated, but makes no mention of Resource B. After terraform apply, when the computed value is re-computed, terraform plan then says that Resource B will be updated.

Certainly I can understand why terraform plan doesn't suggest doing anything to Resource B the first time, because Resource A's computed values haven't been updated. But once they've been updated, it means that the resources dependent on those values need to then be re-evaluated. As it is, they are not actually in a correct state any longer, as shown by the fact that terraform plan then schedules new work for a second run.

It seems like there is a tradeoff here: either committing to idempotency and re-checking other resources that have dependencies on computed values (or simply deferring read/update on those until after the resources they depend on are finished updating), or committing to the stated plan. Personally I'd prefer the former, with a warning when running terraform plan that there are dependencies on computed resources and as such the final results may not match the shown output.

@mitchellh After discussion with @phinze he suggested highlighting/bumping this to ensure that the description in the above comment was noticed (since it is marked waiting for response). If what I described above doesn't match with how you think Terraform behaves I can work up a test case.

Actually, FWIW, right now I'm not running into this behavior. When I run plan/apply, I see many of my resources being refreshed, a tiny pause, and the other two resources that depend on earlier ones then are refreshed.

I don't know if it's due to rebasing on later versions of terraform that had changes or what, but I will close this up until some time I can reliably reproduce it.

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.