CloudProvider: Allow unhandled values in metrics list validation

[thepalbi]

We've seen a common use case where customers want to modularize the use of cloud provider observability, into a terraform module, and inject the "service" or "metrics" configuration as variables.

Once such case is the following:

resource "grafana_cloud_provider_aws_cloudwatch_scrape_job" "main" {
  stack_id                = var.stack_id
  name                    = var.name
  aws_account_resource_id = grafana_cloud_provider_aws_account.main.resource_id

  dynamic "service" {
    for_each = var.services
    content {
      name = service.value.namespace

      dynamic "metric" {
        for_each = service.value.metrics
        content {
          name       = metric.key
          statistics = metric.value
        }
      }

      scrape_interval_seconds = service.value.scrape_interval_seconds
      tags_to_add_to_metrics  = service.value.tags_to_add_to_metrics
    }
  }
}

# fed from 

variable "metrics" {
  description = "The default set of metrics and statics for alb"
  type        = map(list(string))
  default = {
    ActiveConnectionCount          = ["Average", "Sum"]
    ClientTLSNegotiationErrorCount = ["Average", "Sum"]
  }
}

When using this in a test module, with the latest version, terraform fails even before planning in the validation stage with:

╷
│ Error: Value Conversion Error
│ 
│   with module.lb-monitoring.grafana_cloud_provider_aws_cloudwatch_scrape_job.accountAlb,
│   on modules/loadbalancer-monitoring/main.tf line 17, in resource "grafana_cloud_provider_aws_cloudwatch_scrape_job" "accountAlb":
│   17: resource "grafana_cloud_provider_aws_cloudwatch_scrape_job" "accountAlb" {
│ 
│ An unexpected error was encountered trying to build a value. This is always an error in the provider. Please report the following to the provider developer:
│ 
│ Received unknown value, however the target type cannot handle unknown values. Use the corresponding `types` package type or a custom type that handles unknown values.
│ 
│ Path: 
│ Target Type: []cloudprovider.awsCWScrapeJobMetricTFModel
│ Suggested Type: basetypes.ListValue

More details in:

Path: 
Target Type: []cloudprovider.awsCWScrapeJobMetricTFModel
Suggested Type: basetypes.ListValue" diagnostic_summary="Value Conversion Error" diagnostic_attribute= diagnostic_severity=ERROR tf_req_id=16f71fe0-ecb7-608c-dc51-a768307e32d2 tf_rpc=ValidateResourceTypeConfig timestamp=2025-01-31T16:10:00.351-0300
2025-01-31T16:10:00.351-0300 [WARN]  provider.terraform-provider-grafana: Response contains warning diagnostic: tf_resource_type=grafana_cloud_provider_aws_cloudwatch_scrape_job @module=sdk.proto diagnostic_detail="list value as string is: <unknown>" diagnostic_severity=WARNING diagnostic_summary="was here" tf_proto_version=5.7 @caller=/Users/pablo/go/pkg/mod/github.com/hashicorp/[email protected]/tfprotov5/internal/diag/diagnostics.go:60 tf_provider_addr=registry.terraform.io/grafana/grafana tf_req_id=16f71fe0-ecb7-608c-dc51-a768307e32d2 tf_rpc=ValidateResourceTypeConfig timestamp=2025-01-31T16:10:00.351-0300
2025-01-31T16:10:00.351-0300 [ERROR] vertex "module.lb-monitoring.grafana_cloud_provider_aws_cloudwatch_scrape_job.accountAlb" error: Value Conversion Error

Which indicates in tf_rpc=ValidateResourceTypeConfig that this came from this bit of type being mapped to the plan config.

Looking at the difference with the other validators, such as this, once can see that the third parameter of ElementsAs, named allows unhandled is used:

diags := req.ConfigValue.ElementsAs(ctx, &customNamespaces, true)

Reading more in depth, this comes from that during the validation stage, which is before planning, variables values injected into for_each statements for example, are not resolves until plan, but handled as unknown. That's why allowing this ElementsAs to allow unhandled values such as unknowns is the right choice, and a design decision in terraform.

This PR fixes this.

[github-actions]

In order to lower resource usage and have a faster runtime, PRs will not run Cloud tests automatically.
To do so, a Grafana Labs employee must trigger the cloud acceptance tests workflow manually.

[thepalbi]

@kgeckhart or @andriikushch, if you can take a look at this early next week, that's be cool. A customer found this issue and just found how to address it.

[kgeckhart]

Nice work tracking this one down!