Null computed ListAttribute when data source is read at apply time

[marshallford]

Hello 👋🏼 I apologize if this is a bug in my provider and not the plugin framework. This has been a head scratcher, so I thought I would open an issue. Thank you.

Module version

github.com/hashicorp/terraform-plugin-framework v1.13.0

Relevant provider source code

"artifact_queries": schema.MapNestedAttribute{
	Optional:            true,
	NestedObject: schema.NestedAttributeObject{
		Attributes: map[string]schema.Attribute{
			"jq_filter": schema.StringAttribute{
				Required:            true,
				Validators: []validator.String{
					stringIsJQFilter(),
				},
			},
			"results": schema.ListAttribute{
				Computed:            true,
				ElementType:         jsontypes.NormalizedType{},
			},
		},
	},
},

Terraform Configuration Files

See here: marshallford/terraform-provider-ansible#79

Debug Output

https://gist.github.com/marshallford/38c159bd2ab5f7bb11119232bb717d8e

Expected Behavior

The data source attribute artifact_queries.example.results should be considered "unknown" until the deferred read. After the data source has been read the normal graph order of operations should allow the data source attribute to be referenced in resources/outputs/etc.

Actual Behavior

The ListAttribute is not shown in the Terraform plan output (with (known after apply)) and Terraform evaluates the attribute as null before the data source has been read. In contrast, another computed attribute (ansible_options.known_hosts, a ListAttribute within a SingleNestedAttribute) can be referenced when the data source is deferred without issue.

Example

  # data.ansible_navigator_run.test will be read during apply
  # (config refers to values not yet known)
 <= data "ansible_navigator_run" "test" {
      + ansible_navigator_binary = "/home/marshall/Documents/Projects/terraform-provider-ansible/.venv/bin/ansible-navigator"
      + ansible_options          = (known after apply)
      + artifact_queries         = {
          + "example" = {
              + jq_filter = "{foobar: \"test\"}"
              // !! Missing "results = (known after apply)" here !!
            },
        }
      + command                  = (known after apply)
...

Steps to Reproduce

1. terraform init
2. terraform plan

References

Sibling issue: marshallford/terraform-provider-ansible#79

[marshallford]

@austinvalle Sorry to bother -- I've spent the last week digging through GH issues across the various terraform repositories as well as the Hashi forums and I've come up empty. Any pointers? I think this issue applies to deferred ephemeral resources as well. Thanks.

[austinvalle]

Hey @marshallford 👋🏻 , I'll need to dig deeper later this week, but based on what you're describing and this line from your log:

2025-03-05T15:25:21.003-0600 [TRACE] planDataSource: data.ansible_navigator_run.test configuration not fully known yet, so deferring to apply phase

I think this could be a bug in Terraform core. If you're looking to verify that in the meantime, you could try using the data source with older versions of Terraform (nested attributes were introduced in TF 1.0+). If it is a bug in TF Core, it shouldn't be too difficult for us to recreate that.

---

Despite the log method name 😅 , data sources don't "really plan", so I wouldn't expect any of your data source code to be executed here before the error. The reason you're likely not observing this with the resource equivalent is because it does actually plan, and your provider is returning an unknown value properly.

I'll carve out some time later this week to take a deeper look 👍🏻

[austinvalle]

@marshallford 👋🏻

Alright, I have reproduced the issue and believe it is a Terraform core bug specifically with MapNestedAttribute w/ computed attributes underneath. I also confirmed that this behavior has existed in core since at least Terraform v1.4.7 (probably well before that, however I'm too lazy to create an example not using terraform_data 😆)

I created an issue in the core repository that you can subscribe to if you're curious about the details. Will leave this issue open until that is resolved 👍🏻

hashicorp/terraform#36653

[marshallford]

Thank you for doing to legwork to reproduce this and submit the core issue. Much appreciated 👍

[austinvalle]

Looks like the upstream bug fix has been merged and should be available in the next release of Terraform core (v1.11.2): hashicorp/terraform#36653

I built terraform from source and tested it out since I had that re-creation example handy, and it looks good now!

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

Changes to Outputs:
  + test = {
      + nested_map = {
          + key1 = {
              + computed_attr = (known after apply) # <--- was previously null, now correctly unknown!
              + required_attr = (known after apply)
            }
        }
      + nested_obj = {
          + computed_attr = (known after apply)
          + required_attr = (known after apply)
        }
    }

I'm not 100% sure when their next release is planned, but they typically do a patch release every couple weeks. If you run into trouble with Terraform v1.11.2, we can re-open this!

[marshallford]

Awesome! I look forward to the next patch release! Thanks again.

[marshallford]

1.11.2 did not include the fix. Will the change not be included until 1.12.0? That would surprise me given the surface area of the bug.

[austinvalle]

Apologies! I'm not on the core team so I didn't notice that this bug fix was merged after their 1.11.2 cutoff date 🙁; it'll be released in 1.11.3.

That would surprise me given the surface area of the bug.

While it is a bug in the core plan logic, it's still kind of an edge case since data sources only use that plan function as a convenience when deferring. The core plan logic's main path is managed resources which can never have a prior value of unknown.