cloudflare_address_map default_sni not applied on resource create

[edavie]

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 Version: 1.1.6
Cloudflare Provider Version: 4.37.0

Affected resource(s)

cloudflare_address_map

Terraform configuration files

resource "cloudflare_address_map" "sni-address-map" {
  account_id  = snip
  description = "snip"
  default_sni = "snip"
  enabled     = true

  ips { ip = "snip" }

  memberships {
    identifier = snip
    kind       = "account"
  }
}

Link to debug output

https://gist.github.com/edavie/55e726f9c6720617484071ef1beea88e

Panic output

No response

Expected output

When specifying the default_sni parameter within cloudflare_address_map this should be set on the address map within Cloudflare. This can be verified outside of terraform with an API call to https://api.cloudflare.com/client/v4/accounts/snip/addressing/address_maps

Which would illustrate "default_sni" being set to the value passed in the parameter for the relevant address map.

Actual output

For address map resource creates the default_sni parameter is not added to the payload (missing from https://github.com/cloudflare/terraform-provider-cloudflare/blob/v4.39.0/internal/sdkv2provider/resource_cloudflare_address_map.go#L33-L66). This is confirmed by calling the Cloudflare API directly at https://api.cloudflare.com/client/v4/accounts/snip/addressing/address_maps.

For address map resource updates the default_sni parameter is added to the payload and set properly within Cloudflare (again verifiable via Cloudflare's API). This is because update is properly referencing default_sni: https://github.com/cloudflare/terraform-provider-cloudflare/blob/v4.39.0/internal/sdkv2provider/resource_cloudflare_address_map.go#L105-L108

resourceCloudflareAddressMapCreate needs to be updated to include default_sni.

Steps to reproduce

1 - Run terraform apply to create resource, confirm no default_sni set via CF API call
2 - Re-run terraform apply to update resource (TF observes no default_sni is set on CF side), confirm default_sni is now set

Additional factoids

No response

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.

[edavie]

I did not upload a full tf_log as I believe I've documented above what needs to be done to rectify this particular issue. Please let me know if that is not the case!

[github-actions]

Marking this issue as stale due to 30 days of inactivity. This helps our maintainers find and focus on the active issues. If this issue receives no comments in the next 7 days it will automatically be closed. Maintainers can also remove the lifecycle/stale label.
If this issue was automatically closed and you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. Thank you!

[github-actions]

This issue was closed because it has been stalled for 7 days with no activity.