Bad import state for identity block in azurerm_logic_app_workflow

[seblatre]

Is there an existing issue for this?

• [X] I have searched the existing issues

Community Note

• Please vote on this issue by adding a :thumbsup: reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave comments along the lines of "+1", "me too" or "any updates", they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment and review the contribution guide to help.

Terraform Version

1.9.5

AzureRM Provider Version

3.116.0

Affected Resource(s)/Data Source(s)

azurerm_logic_app_workflow

Terraform Configuration Files

resource "azurerm_logic_app_workflow" "logic_app" {

  name                = "my-wonderful-logic-app"
  location            = "westeurope"
  resource_group_name = "DEVA42TEST

  identity {
    type = "SystemAssigned"
  }

  lifecycle {
    ignore_changes = [parameters, workflow_parameters, enabled]
  }
}

variable "group" {
  description = "The group to add members to"
  type = object({
    display_name = string
    id           = string
    object_id    = string
  })
}

resource "azuread_group_member" "member" {
  group_object_id  = var.group.object_id
  member_object_id = azurerm_logic_app_workflow.logic_app.identity[0].principal_id
}

Debug Output/Panic Output

Not useful for this use case

Expected Behaviour

Being able to Import an existing logic app without system managed identity yet

Actual Behaviour

• When the logic app is created from scratch, the following plan is prepared with identity.principal_id as "known after apply" which is expected:

  # azurerm_logic_app_workflow.logic_app will be created
  + resource "azurerm_logic_app_workflow" "logic_app" {
    + access_endpoint                 = (known after apply)
    + connector_endpoint_ip_addresses = (known after apply)
    + connector_outbound_ip_addresses = (known after apply)
    + enabled                         = true
    + id                              = (known after apply)
    + location                        = "westeurope"
    + name                            = "my-wonderful-logic-app"
    + resource_group_name             = "DEVA42TEST"
    + workflow_endpoint_ip_addresses  = (known after apply)
    + workflow_outbound_ip_addresses  = (known after apply)
    + workflow_schema                 = "https://schema.management.azure.com/providers/Microsoft.Logic/schemas/2016-06-01/workflowdefinition.json#"
    + workflow_version                = "1.0.0.0"
  
    + identity {
        + principal_id = (known after apply)
        + tenant_id    = (known after apply)
        + type         = "SystemAssigned"
      }
  }

• When the logic app already exist outside Terraform with a system managed identity and imported, the following plan is prepared with identity.principal_id as "known" which is expected as well:

  # azurerm_logic_app_workflow.logic_app will be imported
  resource "azurerm_logic_app_workflow" "logic_app" {
      access_endpoint                    = "https://prod-53.westeurope.logic.azure.com:443/workflows/..."
      connector_endpoint_ip_addresses    = []
      connector_outbound_ip_addresses    = [...]
      enabled                            = true
      id                                 = "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/DEVA42TEST/providers/Microsoft.Logic/workflows/my-wonderful-logic-app"
      integration_service_environment_id = null
      location                           = "westeurope"
      logic_app_integration_account_id   = null
      name                               = "my-wonderful-logic-app"
      parameters                         = {}
      resource_group_name                = "DEVA42TEST"
      tags                               = {}
      workflow_endpoint_ip_addresses     = [...]
      workflow_outbound_ip_addresses     = [...]
      workflow_parameters                = {}
      workflow_schema                    = "https://schema.management.azure.com/providers/Microsoft.Logic/schemas/2016-06-01/workflowdefinition.json#"
      workflow_version                   = "1.0.0.0"
  
      identity {
          identity_ids = []
          principal_id = "zzzzzzzz-zzzz-zzzz-zzzz-zzzzzzzzzzzz"
          tenant_id    = "yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy"
          type         = "SystemAssigned"
      }
  }

• But when the logic app already exist outside Terraform without system managed identity and imported, the following plan is prepared with identity.principal_id as "undefined" which shouldn't be expected:

  # azurerm_logic_app_workflow.logic_app will be updated in-place
  # (imported from "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/DEVA42TEST/providers/Microsoft.Logic/workflows/my-wonderful-logic-app")
  ~ resource "azurerm_logic_app_workflow" "logic_app" {
      access_endpoint                    = "https://prod-114.westeurope.logic.azure.com:443/workflows/..."
      connector_endpoint_ip_addresses    = []
      connector_outbound_ip_addresses    = [...]
      enabled                            = true
      id                                 = "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/DEVA42TEST/providers/Microsoft.Logic/workflows/my-wonderful-logic-app"
      integration_service_environment_id = null
      location                           = "westeurope"
      logic_app_integration_account_id   = null
      name                               = "my-wonderful-logic-app"
      parameters                         = {}
      resource_group_name                = "DEVA42TEST"
      tags                               = {}
      workflow_endpoint_ip_addresses     = [...]
      workflow_outbound_ip_addresses     = [...]
      workflow_parameters                = {}
      workflow_schema                    = "https://schema.management.azure.com/providers/Microsoft.Logic/schemas/2016-06-01/workflowdefinition.json#"
      workflow_version                   = "1.0.0.0"
  
    + identity {
        + type = "SystemAssigned"
      }
  }

  And so in this last case, the creation of the group membership in AD is failing because principal_id is considered as "null" and not as "know after apply":

  │ Error: Missing required argument
  │
  │   with azuread_group_member.member,
  │   on main.tf line x, in resource "azuread_group_member" "member":
  │    x:   member_object_id = azurerm_logic_app_workflow.logic_app.identity[0].principal_id
  │
  │ The argument "member_object_id" is required, but no definition was found.

Steps to Reproduce

1. A logic app must be already existing on Azure with no Managed Identity with resource id /subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/DEVA42TEST/providers/Microsoft.Logic/workflows/my-wonderful-logic-app
2. Ask the logic app to be imported in the state through import block in a .tf file

   import {
   to = azurerm_logic_app_workflow.logic_app
   id = "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/DEVA42TEST/providers/Microsoft.Logic/workflows/my-wonderful-logic-app"
   }

3. Launch a plan terraform plan

Important Factoids

None

References

No response

[ziyeqf]

Hi @seblatre, thanks for opening the issue.

There might 2 issues involved, first is the provider does not produce the correct plan value. Second is the somehow azuread_group_member. member did not get the value of azurerm_logic_app_workflow.logic_app.identity[0].principal_id after the modification finished. I'm still working on it and will let you know once I made progress.

Thanks

[seblatre]

@ziyeqf, for what I could understand here is that the plan is not complete in the third case I presented. Looking at the plan, there is absolutely no mention of identity.principal_id (with a value or a not yet known value). Without that, I think that the engine is lost and not able to propose any value for this field (hence the no definition found error)

[ziyeqf]

Hi @seblatre,

I have reproduced this issue before but with the latest Terraform and provider, it works properly, it might because of this PR(https://github.com/hashicorp/terraform/pull/35644) on Terraform, do you mind try it again? my versions:

❯❯ tf version   
Terraform v1.9.7
on darwin_arm64
+ provider registry.terraform.io/hashicorp/azurerm v4.5.0

my configuration:

provider "azurerm" {
  features {}
}

resource "azurerm_resource_group" "test" {
  name     = "test-logic"
  location = "westus2"
}

resource "azurerm_logic_app_workflow" "test" {
  name                = "test-workflow"
  location            = azurerm_resource_group.test.location
  resource_group_name = azurerm_resource_group.test.name

  lifecycle {
    ignore_changes = [ tags, identity ]
  }
}

import {
  id = "/subscriptions/<sub_id>/resourceGroups/test-logic/providers/Microsoft.Logic/workflows/test-logic"
  to = azurerm_logic_app_workflow.test
}

output "identity_id" {
  value = azurerm_logic_app_workflow.test.identity[0].principal_id
}

[seblatre]

Hello @ziyeqf, I just saw you answer but I'm on vacation right now. I'll check that at my return. But that sounds good :)

[seblatre]

Hello @ziyeqf, I just tested the behavior on the following stack:

$ terraform version
Terraform v1.9.8
on windows_amd64
+ provider registry.terraform.io/hashicorp/azurerm v4.5.0
[...]

and just hit the exact same issue.

In your example, I think that the following block is missing in your logic app to reproduce the same issue.

  identity {
    type = "SystemAssigned"
  }

Also the logic app must not have any identity defined on it (set it to off). The use of azuread_group_member resource may be needed as well because I think the issue lies within the plan workflow and just outputting the value may not be sufficient to make the issue appear.

[ziyeqf]

Oh, I reproduced the issue, still looking into it