We are seeing plans with the following: ``` ╷ │ Error: Invalid count argument │ │ on /terraform_data/modules/msteams_workflow_notifications/main.tf line 4, in resource "random_id" "topic_name": │ 4: count = var.topic_id == null ? 1 : 0 │ │ The "count" value depends on resource attributes that cannot be determined until apply, so Terraform cannot predict how many instances will be created. To work around this, use the -target argument to first apply only the resources that │ the count depends on. ╵ ``` This is due to the following use in [monitoring.tf](https://gitlab.developers.cam.ac.uk/uis/devops/infra/gcp-product-factory/-/blob/master/monitoring.tf?ref_type=heads#L89) in gcp-product-factory: ```tf module "msteams_workflow_notifications" { source = "gitlab.developers.cam.ac.uk/uis/gcp-pubsub-to-ms-teams/devops" version = "~> 1.2" project = local.meta_project_id region = var.region msteams_channel_webhook_urls = var.msteams_channel_webhook_urls topic_id = google_pubsub_topic.default_monitoring.id } ``` The problem here is that, until `google_pubsub_topic.default_monitoring` is created, terraform cannot know what the value of `google_pubsub_topic.default_monitoring.id` is and so it doesn't know whether to plan to create the `google_pubsub_topic.default` resource within this module. Having resources whose existence depends on the value of arguments is a common problem with terraform modules and the usual pattern is to have an explicit "create" flag. Confer [the create_... arguments in the Google Load Balancer module](https://registry.terraform.io/modules/GoogleCloudPlatform/lb-http/google/latest). This allows the user of the module to signal that they expect something to be provided before the value is known. So, for this module: 1. Add a `create_default_topic` variable, which defaults to `true` and update the resources in `main.tf`: ```tf resource "random_id" "topic_name" { count = var.create_default_topic ? 1 : 0 byte_length = 4 prefix = "pubsub2teams-" keepers = {} } resource "google_pubsub_topic" "default" { count = var.create_default_topic ? 1 : 0 project = var.project name = random_id.topic_name[0].hex } ``` 2. **Keep** the definition of `local.topic_id` the same as it is. The effect of specifying the `topic_id` as above now "fails safe" in that a redundant MS Teams topic is created. Users of the module can then update call sites. For the motivating example: ```tf module "msteams_workflow_notifications" { source = "gitlab.developers.cam.ac.uk/uis/gcp-pubsub-to-ms-teams/devops" version = "~> 1.2" project = local.meta_project_id region = var.region msteams_channel_webhook_urls = var.msteams_channel_webhook_urls create_default_topic = false topic_id = google_pubsub_topic.default_monitoring.id } ``` The use of an explicit `create_default_topic = false` allows the user of the module to indicate that it intends to provide `topic_id` but allows the plan to proceed if `google_pubsub_topic.default_monitoring` has not yet been created.