Output value "Dynamic" in a first time state

I’m trying to understand the diff between the two attached state files.

The environment… any TF 1.3.x version; any AWS provider ~> 4.0. I haven’t exhaustively tested every possibility, but random combinations all show same error.

I’m developing a module to do a bunch of stuff with AWS IAM. And in the module I have some “unit tests” that I’m applying. These aren’t with the experimental testing framework, nor apparentlymart/testing. My unit tests are simple TF config.

When I start with a clean, “empty” state and then do an apply I get sorted.1.txt as my state file. I then ~immediately~ do another apply and I get sorted.2 as my state file. That second apply detects an output change. If you diff those, you’ll see the change at line 25 - "result": "dynamic". I’ve sanitized the state files a bit, so if there is something that’s syntactically wrong, that’s just poor editing on my part.

This is a small piece of a larger and more complex module, so I’m hoping to avoid sharing that as it would take an awful lot of explaining to get us to a common, usable starting point.

Instead, I’m hoping to get a sense of what might be the cause and where I might start looking and, possibly, create a test case that is consumable. Why does the first state (coming from an empty state) show “dynamic” and what does it mean? And why does it disappear after the 2nd and all future applies? This borders on a minor annoyance, but I’d like to get an understanding of what’s going on.

I have a niggling suspicion this has something to do with this being a recursive submodule. IOW… it’s a submodule that calls itself. I can back that out if needed. I’m use a pattern essentially like this.

Any ideas? Thanks!

sorted.1.txt (2.1 KB)
sorted.2.txt (2.9 KB)

I think we would need to see a more complete configuration example to determine what is going on here. Recursive modules are not allowed (they will just call themselves infinitely), so there must be something else happening.

The usual suspect when values require a second apply to converge is that you are using a data source to read a resource which is managed elsewhere in the configuration. This causes the data source to return different values before and after the associated managed resource is applied.

The difference in the posted files shows there is no difference at all in the output value, but there is a difference in the computed type of the value.

In the first file, Terraform infers several layers of nested object structure and then ends up uncertain what type a deeply nested attribute will have, and labels it as dynamic.

In the second file, Terraform has apparently propagated more type information and figures out more precise type information.

It is likely you would need to construct and share a way for other people to reproduce this, for anyone to look into it further.