v5-rc1 - cloudflare_zero_trust_access_application for private destination. OpenApi spec producing a model that's not accepted by the upstream server

[robson83]

Confirmation

• This is a bug with an existing resource and is not a feature request or enhancement. Feature requests should be submitted with Cloudflare Support or your account team.
• I have searched the issue tracker and my issue isn't already found.
• I have replicated my issue using the latest version of the provider and it is still present.

Terraform and Cloudflare provider version

Terraform v1.10.4
on darwin_arm64

Affected resource(s)

cloudflare_zero_trust_access_application

Terraform configuration files

resource "cloudflare_zero_trust_access_application" "internal_pgsql_test" {
  name="internal_pgsql_test"
  type = "self_hosted"
  account_id  = var.account_id
  allow_authenticate_via_warp = true
  app_launcher_visible = false
  auto_redirect_to_identity = true 

  destinations = [{
    type="private"
    uri="10.0.0.1/32:5432"
  }]


  policies = [{
    id = "..."
    precedence = 0
  }]
  
}

Link to debug output

https://gist.github.com/robson83/0a0d2fd86c2d0de4dd9217cfa6c62bae

Panic output

No response

Expected output

Application to be created - following the same behavior that happens when using the frontend.

Actual output

errors": [
{
"code": 12130,
"message": "access.api.error.invalid_request: domain does not belong to zone"
}
]

Steps to reproduce

1. Create a cloudflare_zero_trust_access_application, setting the destination as private.
2. Run terraform apply

Additional factoids

Creating the application via dashboard, it works properly. Upon inspecting the json generated by the dashboard and sent to cloudflare API, noticed there is a difference from what the OpenAPI spec is generating via Stainless.

v5-rc1 generates a simple json containing type and uri. Previous versions of that json added other attributes, such as port_range, cidr.

#1 see (current tag):

terraform-provider-cloudflare/internal/services/zero_trust_access_application/model.go

Line 78 in b386b1f

type ZeroTrustAccessApplicationDestinationsModel struct {

#2 see (next branch):

terraform-provider-cloudflare/internal/services/zero_trust_access_application/model.go

Line 79 in e7965cd

Type types.String `tfsdk:"type" json:"type,optional"`

I compiled the plugin locally and changed the models to the #2 format and everything works fine.

Now the question is if it's a bug, or if a simplified version of the api is coming, because of this comment in the current openapi spec.

Public destinations can include a domain and path with wildcards. Private destinations are an early access feature and gated behind a feature flag. Private destinations support private IPv4, IPv6, and Server Name Indications (SNI) with optional port ranges

Nevertheless, it's not working as it should.

References

No response

[github-actions]

Community Note

Voting for Prioritization

• Please vote on this issue by adding a 👍 reaction to the original post to help the community and maintainers prioritize this request.
• Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request.

Volunteering to Work on This Issue

• If you are interested in working on this issue, please leave a comment.
• If this would be your first contribution, please review the contribution guide.

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

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

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