stackit_routing_table / stackit_routing_table_route: stale state after the network area is recreated (Delete only treats HTTP 404 as gone)

[devpie]

Description

When a stackit_network_area is deleted and recreated (for example by a change that forces replacement), the platform deletes all routing tables of that area together with their routes. The Terraform state still contains the stackit_routing_table and stackit_routing_table_route resources, and every following operation on them fails.

Cause in the provider (verified, see the reproduction comment below): Read() of stackit_routing_table reports an error diagnostic on HTTP 404 instead of removing the resource from state (stackit/internal/services/iaas/routingtable/table/resource.go), so every refresh of the stale resource fails. Delete() handles 404 correctly. The first assumption that the IaaS API answers HTTP 400 for these requests did not hold for routing tables and routes; they answer 404. The API does answer 400 (region not enabled) for a deleted regional network area configuration while the network area still exists, which stackit_network_area_region does not handle (separate problem).

A second observation in stackit_routing_table.Read(): it calls resp.State.RemoveResource() after any API error. That call is dead code, because the error diagnostic set just before it makes Terraform keep the prior state; the fix drops it and removes the resource from state only on 404.

Steps to reproduce

resource "stackit_network_area" "example" {
  organization_id = var.organization_id
  name            = "example"
  # ...
}

resource "stackit_routing_table" "example" {
  organization_id = var.organization_id
  network_area_id = stackit_network_area.example.network_area_id
  name            = "example"
}

resource "stackit_routing_table_route" "example" {
  organization_id  = var.organization_id
  network_area_id  = stackit_network_area.example.network_area_id
  routing_table_id = stackit_routing_table.example.routing_table_id
  destination = {
    type  = "cidrv4"
    value = "10.0.0.0/24"
  }
  next_hop = {
    type = "blackhole"
  }
}

1. terraform apply
2. Change an attribute of stackit_network_area.example that forces replacement, or delete and recreate the network area outside of Terraform
3. terraform apply (the same happens with terraform plan, and with a removed block that uses destroy = true)

Actual behavior

The apply fails with an API error for the old routing table (the routing table does not exist). The only way out is a removed block with destroy = false for the routing table and its routes, followed by a normal apply that creates them again.

Expected behavior

• Delete() treats the routing table and its routes as already deleted when the network area is gone, like it does for HTTP 404.
• Read() removes the resources from state when they are gone and keeps the state on any other error.
• The docs of stackit_routing_table and stackit_routing_table_route mention that the platform deletes routing tables and routes together with their network area.

Environment

Reported by the person who hit this:

• Terraform version: v1.15.8
• Version of the STACKIT Terraform provider: v0.114.0
• Reproduced from Azure DevOps (Microsoft-hosted ubuntu-latest agents), from macOS 25.6, and from WSL with Ubuntu 24.04 LTS

My own reproduction (see the comments below):

• OS: macOS 26.6.2 (arm64)
• Terraform version: OpenTofu v1.12.6
• Version of the STACKIT Terraform provider: v0.114.0

Additional information

Routing tables are still a public preview feature. Fix: #1750.

[devpie]

Reproduced on 2026-09-07 with the released provider. Versions and the actual API behaviour:

• OS: macOS 26.6.2 (arm64)
• OpenTofu v1.12.6
• STACKIT Terraform provider v0.114.0

Setup: stackit_network_area + stackit_network_area_region (eu01) + stackit_routing_table + stackit_routing_table_route created with the provider, then the regional configuration and afterwards the network area deleted outside of Terraform (stackit network-area region delete, then stackit network-area delete).

API responses afterwards (all GET, with the area deleted):

Endpoint	Status
network area	404 {"code":404,"msg":"resource not found: area"}
regional configuration eu01	404, same body
routing table	404, same body
route	404, same body

While the area still existed and only the regional configuration was deleted: routing table and route also answered 404 resource not found: area; the regional configuration itself answered 400 {"code":400,"msg":"region not enabled"}.

So the routing table endpoints answer 404, not 400. The refresh with v0.114.0 still fails:

Error: Reading routing table
routing table with ID "5e3fe503-…" does not exist in organization "03a34540-…".

Cause: stackit_routing_table.Read() turns the 404 into an error diagnostic instead of removing the resource from state (utils.LogError followed by RemoveResource; Terraform keeps the prior state when a read reports an error). Delete() handles the 404 correctly. That matches the report: a removed block with destroy = true refreshes the resource first and fails there; destroy = false skips the refresh.

With the build from #1750: tofu plan -refresh-only reports all four resources as deleted (exit 0), and tofu destroy -refresh=false succeeds for the already deleted routing table and route.

Side finding, not covered by #1750: with the area present but its regional configuration deleted, stackit_network_area_region.Read() fails on the 400 "region not enabled" (it only treats 404 as gone) and blocks every plan while that resource is in state.

[devpie]

Second run, same setup, to pin down how the cascade happens:

• stackit network-area delete on an area with an enabled regional configuration is refused: 409 {"code":409,"msg":"conflict: regions are still enabled"}.
• stackit network-area region delete succeeds and takes the routing tables and routes of that region with it; afterwards they answer 404 resource not found: area, and the area can be deleted.

This is the order stackit_network_area.Delete() uses as well (regions first, then the area), so any flow that deletes the area without destroying the routing tables through Terraform first (another state, -target, portal, CLI) ends up with the stale entries.

Results identical to the first run: every GET (area, regional configuration, routing table, route) answers 404; v0.114.0 fails the refresh with Error: Reading routing table; the build from #1750 reports all four resources as deleted.