azurerm_route_table tries to recreate when it shouldn't

[evmimagina]

Is there an existing issue for this?

• I have searched the existing issues

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or "me too" comments, 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

Terraform Version

latest

AzureRM Provider Version

latest

Affected Resource(s)/Data Source(s)

azurerm_route_table

Terraform Configuration Files

resource "azurerm_route_table" "main" {
  name                = var.table_name
  location            = var.location
  resource_group_name = var.resource_group_name
  disable_bgp_route_propagation = var.disable_bgp_route_propagation

  dynamic "route" {
    for_each = var.routes
    content {
        name                   = route.value.name
        address_prefix         = route.value.address_prefix
        next_hop_type          = route.value.next_hop_type
        next_hop_in_ip_address = route.value.next_hop_in_ip_address
    }
  }

  tags                = var.tags

}

Debug Output/Panic Output

#During the apply phase

│ Error: Provider produced inconsistent final plan
│ 
│ When expanding the plan for
│ module.hub_snet_apps_routes.azurerm_route_table.main to include new values
│ learned so far during apply, provider
│ "registry.terraform.io/hashicorp/azurerm" produced an invalid new value for
│ .route: planned set element
│ cty.ObjectVal(map[string]cty.Value{"address_prefix":cty.StringVal("10.10.1.8/29"),
│ "name":cty.StringVal("Direct_VNET_NVA-LAN-Side_Network"),
│ "next_hop_in_ip_address":cty.NullVal(cty.String),
│ "next_hop_type":cty.StringVal("VnetLocal")}) does not correlate with any
│ element in actual.
│ 
│ This is a bug in the provider, which should be reported in the provider's
│ own issue tracker.
╵

Expected Behaviour

the route is created correctly the first time, the second time shouldn't try to recreate it again.

Actual Behaviour

the second time we run a terraform apply, it tries to recreate the routes, it fails with those routes that don't use the next_hop_in_ip_address property.

We've tried to set for next_hop_in_ip_address a value of "", but then it fails because is not an accepted value.

Steps to Reproduce

No response

Important Factoids

No response

References

Maybe yes, I have searched for this and it seems they might be related as there are problems with the azurerm_route_table but I don't think they look exactly the same. This looks very similar to the issue I'm raising: #19182

[evmimagina]

#Workaround module code

`
resource "azurerm_route_table" "main" {
name = var.table_name
location = var.location
resource_group_name = var.resource_group_name
disable_bgp_route_propagation = var.disable_bgp_route_propagation

/*
dynamic "route" {
for_each = var.routes
content {
name = route.value.name
address_prefix = route.value.address_prefix
next_hop_type = route.value.next_hop_type
next_hop_in_ip_address = route.value.next_hop_in_ip_address
}
}
*/ #WA approach due bug in provider
dynamic "route" {
for_each = var.routes
content {
name = route.value.name
address_prefix = route.value.address_prefix
next_hop_type = route.value.next_hop_type
next_hop_in_ip_address = route.value.next_hop_in_ip_address
}
}
dynamic "route" {
for_each = var.routes_without_next_hop_in_ip_address
content {
name = route.value.name
address_prefix = route.value.address_prefix
next_hop_type = route.value.next_hop_type
}
}

tags = var.tags

}
`

[sinbai]

@evmimagina thanks for opening this issue. Could you provide the Terraform log and complete output in the screenshot below to help troubleshoot?

[evmimagina]

Hi @sinbai ,

Sorry but I don't keep the failing executions and because I've applied the workaround , I wouldn't like to roll-back my code to reproduce the BUG again (I think it's the same as on the tracked request: #19182).

This is not an issue, it's a bug, I think you can reproduce it just trying to create a route with the following config:

`
resource "azurerm_route_table" "main" {
name = var.table_name
location = var.location
resource_group_name = var.resource_group_name

route {
name = route.value.name
address_prefix = route.value.address_prefix
next_hop_type = "VnetLocal"
next_hop_in_ip_address = null
}

}
`

The first "apply" execution will be successful but during the next "apply" it will fail because it tries to replace something that it shouldn't (as you can see on the screenshot).

[sinbai]

Hi @evmimagina , thanks for your quick reply. Unfortunately, I could not repro it by the following tf config, could you repro with it on your side? If yes, could you share the Terraform log and complete output to help troubleshoot?

provider "azurerm" {
  features {}
}

terraform {
  required_providers {
    azurerm = {
      source = "hashicorp/azurerm"
	  version = "3.46.0"
    }
  }
}
resource "azurerm_resource_group" "test" {
  name     = "0303"
  location = "eastus"
}

resource "azurerm_route_table" "test" {
  name                = "testrt0303"
  location            = azurerm_resource_group.test.location
  resource_group_name = azurerm_resource_group.test.name
  

route {
   name = "testroute0303"
   address_prefix = "10.1.0.0/16"
   next_hop_type = "VnetLocal"
   next_hop_in_ip_address = null
  }
}

Run terraform apply for the first time:

Run terraform apply for the second time:

[rcskosir]

Thanks for taking the time to submit this. @sinbai was unable to reproduce this behavior. We’re going to close this issue for now, but if you run into this again with the latest Terraform and Provider versions, please feel free to open a new issue.

[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 have 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.