Nested Computed Attributes for Block Types

[skorfmann]

The resource Kinesis Analytics Application has nested computed attributes for block types which aren't listed on the documentation. I think it makes sense to ignore those attributes. Thoughts?

      "inputs": {
        "nesting_mode": "list",
        "block": {
          "attributes": {
            "id": {
              "type": "string",
              "computed": true
            },
            "name_prefix": {
              "type": "string",
              "required": true
            },
            "starting_position_configuration": {
              "type": [
                "list",
                [
                  "object",
                  {
                    "starting_position": "string"
                  }
                ]
              ],
              "computed": true
            },
            "stream_names": {
              "type": [
                "set",
                "string"
              ],
              "computed": true
            }
          }

The Go Schema defines it as expected:

						"starting_position_configuration": {
							Type:     schema.TypeList,
							Computed: true,
							Elem: &schema.Resource{
								Schema: map[string]*schema.Schema{
									"starting_position": {
										Type:     schema.TypeString,
										Computed: true,
									},
								},
							},
						},
						"stream_names": {
							Type:     schema.TypeSet,
							Computed: true,
							Elem:     &schema.Schema{Type: schema.TypeString},
						},

[skorfmann]

That's what would be generated from the schema.

export class KinesisAnalyticsApplicationInputsStartingPositionConfiguration extends ComplexComputedList {

  // starting_position - computed: true, optional: false, required: true
  public get startingPosition() {
    return this.getStringAttribute('starting_position');
  }
}

export interface KinesisAnalyticsApplicationInputs {
  // ...
  readonly startingPositionConfiguration: KinesisAnalyticsApplicationInputsStartingPositionConfiguration;
  // ...
}

At the moment, these anonymous interfaces are only usable to provide data. Therefore it doesn't make sense to provide accessors deeply nested in there. In this case, it would even be invalid since the Terraform provider wouldn't be able to handle these attributes.

[skorfmann]

This seems to be somewhat related hashicorp/terraform-provider-aws#7551

[DanielMSchmidt]

We seem to support these now: https://github.com/hashicorp/cdktf-provider-aws/blob/fb3b04509dead093f17fac63fe807b78c59a86c5/src/kinesis/kinesis-analytics-application.ts#L1016

[github-actions]

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've 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.