"Configuration for import target does not exist" on resources when conditionally loading modules

[tjrobinson]

Terraform Version

Terraform v1.10.4
on windows_amd64
+ provider registry.terraform.io/hashicorp/azuread v2.53.1

Terraform Configuration Files

https://github.com/tjrobinson/terraform-validation-issue

Debug Output

Available upon request.

Expected Behavior

Prior to Terraform 1.9 the plan completes successfully. I've confirmed this by downgrading to Terraform 1.8.3.

I believe this change to be the cause:
https://developer.hashicorp.com/terraform/language/v1.9.x/upgrade-guides#invalid-import-blocks

Actual Behavior

> terraform validate 
Success! The configuration is valid.

> terraform plan -var-file .\development.tfvars
module.development[0].azuread_access_package_catalog.development_catalog: Preparing import... [id=ec8b328e-6b23-4cb0-b3a3-bcd7cbebf84d]
module.development[0].azuread_access_package_catalog.development_catalog: Refreshing state... [id=ec8b328e-6b23-4cb0-b3a3-bcd7cbebf84d]

Planning failed. Terraform encountered an error while generating this plan.

╷
│ Error: Configuration for import target does not exist
│ 
│ The configuration for the given import module.production[0].azuread_access_package_catalog.production_catalog does not exist. All target
│ instances must have an associated configuration to be imported.

Steps to Reproduce

1. terraform init
2. terraform apply

Additional Context

We're using modules conditionally to be able to have different resource configuration in different environments - for example Development and Production.

The resources sit inside the different modules, but imports have to sit at the root level.

The new validation, whilst great for most things, leaves us unable to upgrade beyond Terraform 1.8.

We can't make the imports conditional as far as I know?

References

No response

Generative AI / LLM assisted development?

No response

[jbardin]

Hi @tjrobinson,

The behavior you see here is what was expected, with the prior behavior being the actual bug. If an active import block can't find the associated resource instance it should return an error because the configuration is incorrect. The for_each data for the import block should follow the same data used to expand the module and resource instances being imported for consistency.

Conditionally importing resources however is something we intend to look into some more, so we can keep this open as an enhancement request to try and come up with a smoother workflow.

[tjrobinson]

Hi @jbardin

Thanks for your quick response. I'd not thought of using for_each on the import blocks.

This is what I've come up with so far and I think it's working ok, though there may be a nicer way to do it:

locals {
  development_catalogs = [
      "development_catalog"
  ]

  production_catalogs = [
      "production_catalog"
  ]
}

import {
  for_each = {
    for catalog in local.development_catalogs : catalog => catalog
    if var.environment == "development"
  }

  to = module.development[0].azuread_access_package_catalog.development_catalog
  id = "ec8b328e-6b23-4cb0-b3a3-bcd7cbebf84d"
}

import {
  for_each = {
    for catalog in local.production_catalogs : catalog => catalog
    if var.environment == "production"
  }
  to = module.production[0].azuread_access_package_catalog.production_catalog
  id = "26c01b34-d2b4-4ca7-a64b-bbdcbbdefaf1"
}

I'm keen to keep the resource ids as-is, e.g. module.development[0].azuread_access_package_catalog.development_catalog because we have hundreds of them so it'd be a lot of work to move them all.

FWIW we're generating the HCL programmatically, so it's not a problem to add a for_each to each existing import.

References:

• Import block expansion with for_each #33932