cloudflare_tunnel_route broken imports and reads

[griffinmyers]

Confirmation

• My issue isn't already found on the issue tracker.
• I have replicated my issue using the latest version of the provider and it is still present.

Terraform and Cloudflare provider version

Terraform v0.12.31

• provider.cloudflare v3.14.0

Affected resource(s)

• cloudflare_tunnel_route

Terraform configuration files

resource cloudflare_tunnel_route route {
  account_id = local.account_id
  tunnel_id  = var.tunnel_id
  network    = "10.01.0.0/16"
  comment    = "My Network"
}

Debug output

Sorry, I'm eliding non-relevant parts of the debug output (there's too much to redact):

cloudflare_tunnel_route.route: Refreshing state... [id=10.01.0.0/16]
2022-05-10T12:53:36.136-0600 [INFO]  plugin.terraform-provider-cloudflare_v3.14.0: 2022/05/10 12:53:36 [DEBUG] Cloudflare API Request Details:
---[ REQUEST ]---------------------------------------
GET /client/v4/accounts/:account_id/teamnet/routes HTTP/1.1
Host: api.cloudflare.com
User-Agent: terraform/0.12.31 terraform-plugin-sdk/2.10.1 terraform-provider-cloudflare/3.14.0
Content-Length: 86
Authorization: Bearer :api_token
Content-Type: application/json
Accept-Encoding: gzip

{
 "is_deleted": false,
 "network_subset": "10.01.0.0/16",
 "network_superset": "10.01.0.0/16"
}
-----------------------------------------------------: timestamp=2022-05-10T12:53:36.135-0600
2022-05-10T12:53:36.300-0600 [INFO]  plugin.terraform-provider-cloudflare_v3.14.0: 2022/05/10 12:53:36 [DEBUG] Cloudflare API Response Details:
---[ RESPONSE ]--------------------------------------
HTTP/2.0 200 OK
Cf-Cache-Status: DYNAMIC
Cf-Ray: 7094e0ee19777ee7-LAX
Content-Type: application/json
Date: Tue, 10 May 2022 18:53:36 GMT
Expect-Ct: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
Server: cloudflare
Set-Cookie: __cflb=:cookie; SameSite=Lax; path=/; expires=Tue, 10-May-22 21:23:37 GMT; HttpOnly
Set-Cookie: __cfruid=:cookie; path=/; domain=.api.cloudflare.com; HttpOnly; Secure; SameSite=None
Vary: Accept-Encoding
X-Envoy-Upstream-Service-Time: 21

{
 "success": true,
 "messages": [],
 "errors": [],
 "result": [
  {
   "network": "10.0.0.0/24",
   "tunnel_id": "deleted-tunnel",
   "comment": "",
   "created_at": "2020-01-01T00:00:00.000000Z",
   "deleted_at": "2020-01-01T00:00:00.000000Z",
   "virtual_network_id": ":virtual_network_id",
   "tunnel_name": "network"
  },
  {
   "network": "10.01.0.0/16",
   "tunnel_id": "live-tunnel",
   "comment": "",
   "created_at": "2020-01-01T00:00:00.000000Z",
   "deleted_at": null,
   "virtual_network_id": ":virtual_network_id",
   "tunnel_name": "name"
  }
 ]
}
-----------------------------------------------------: timestamp=2022-05-10T12:53:36.300-0600
2022-05-10T12:53:36.307-0600 [WARN]  plugin.stdio: received EOF, stopping recv loop: err="rpc error: code = Unavailable desc = transport is closing"

¯\_(ツ)_/¯ 
Terraform version
Go runtime version
CLI args
created provider logger
CLI command args
provider: plugin process exited

An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
-/+ destroy and then create replacement

Terraform will perform the following actions:

  # cloudflare_tunnel_route.route must be replaced
-/+ resource "cloudflare_tunnel_route" "route" {
        account_id = ":account_id"
      + comment    = "My Network"
      ~ id         = "10.01.0.0/16" -> (known after apply)
      ~ network    = "10.0.0.0/24" -> "10.01.0.0/16"
      ~ tunnel_id  = "deleted-tunnel" -> "live-tunnel" # forces replacement
    }

Plan: 1 to add, 0 to change, 1 to destroy.

Panic output

No response

Expected output

I expect to be able to import a cloudflare_tunnel_route resource and have it associate with the correct route in Cloudflare's API. Then, once created or imported, I expect a plan or apply to deterministically resolve the correct route in Cloudflare's API, and yield expected diffs.

Actual output

When importing a cloudflare_tunnel_route resource, the operation can claim success when in fact it associated the resource with the wrong entity in Cloudflare's API. Similarly, when planning or applying an already imported cloudflare_tunnel_route, reading the entity from Cloudflare's API will non-deterministically return the wrong value and yield an incorrect diff.

Steps to reproduce

1. Create a cloudflare_tunnel_route and then delete it. It should be "soft deleted" in Cloudflare's API.
2. Create another cloudflare_tunnel_route.
3. Run a terraform plan. Spuriously, the route deleted in step (1) will be associated with the one in step (2) and yield an incorrect plan.

Additional factoids

I believe the root cause here is this provider, via the Cloudflare Go SDK, making an improper request to Cloudflare's API when pulling the list of account-scoped tunnel routes.

The API docs suggest we make the following request for the list:

GET accounts/:account_identifier/teamnet/routes?is_deleted=false

Specifically, filter parameters ought to be added to the URL querystring.

In actuality, as the debug output here suggests, we're attaching filter parameters in a json request body, which the API ignores:

terraform-provider-cloudflare/cloudflare/resource_cloudflare_tunnel_route.go

Lines 33 to 38 in 2b259f3

	tunnelRoutes, err := client.ListTunnelRoutes(ctx, cloudflare.TunnelRoutesListParams{
	AccountID: accountID,
	IsDeleted: cloudflare.BoolPtr(false),
	NetworkSubset: network,
	NetworkSuperset: network,
	})

https://github.com/cloudflare/cloudflare-go/blob/be41d9e8747c047c8b91993faa3f54c13ee6e0b7/tunnel_routes.go#L73-L92

References

• Feature: add cloudflare_argo_tunnel_route resource #1086

[github-actions]

Thank you for reporting this issue! For maintainers to dig into issues it is required that all issues include the entirety of TF_LOG=DEBUG output to be provided. The only parts that should be redacted are your user credentials in the X-Auth-Key, X-Auth-Email and Authorization HTTP headers. Details such as zone or account identifiers are not considered sensitive but can be redacted if you are very cautious. This log file provides additional context from Terraform, the provider and the Cloudflare API that helps in debugging issues. Without it, maintainers are very limited in what they can do and may hamper diagnosis efforts.

This issue has been marked with triage/needs-information and is unlikely to receive maintainer attention until the log file is provided making this a complete bug report.

[jacobbednarz]

can you please provide the full TF_LOG=DEBUG out per the issue template? https://jacobbednarz.com/tf-log-redactor/ will redact the sensitive information for you irrespective of the log size.

as for the payload body vs params, that has already been addressed via cloudflare/cloudflare-go#873 and was included in v0.39.0 which should make the upcoming release of the provider next week.

[griffinmyers]

can you please provide the full TF_LOG=DEBUG out per the issue template? https://jacobbednarz.com/tf-log-redactor/ will redact the sensitive information for you irrespective of the log size.

Sorry about that -- I'm encountering this issue in a large enough terraform project that the full output is quite large and features lots of sensitive information not covered by your tool. Fallible as I am, I don't trust myself to properly redact everything perfectly while leaving the output in a trustworthy, helpful state for debugging.

That said I think it's pretty clear what the issue is, and I'm glad an upstream change is landing to correct it.

If you'd still like a full debug output, I can spin up a demo cloudflare account / project and hand you a minimally reproducible example; alternatively I'm happy closing this and trusting that the SDK update will fix it.

[griffinmyers]

Thanks folks, it looks like bumping to provider v3.15.0 resolved this for us. Cheers!