cloudflare_zone_settings_override broken on v4.50.0: Error reading setting "aegis" for zone

[ricardbejarano]

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.3
on linux_amd64

- Installed cloudflare/cloudflare v4.50.0 (self-signed, key ID C76001609EE3B136)

This only started happening on v4.50.0 of the provider, which was released 8 hours ago. It worked until then.

Affected resource(s)

• cloudflare_zone_settings_override

Terraform configuration files

resource "cloudflare_zone_settings_override" "all" {
  zone_id = data.cloudflare_zone.all[each.key].id
  settings {
    always_online            = "on"
    // ... (anything except any "aegis" settings)
    zero_rtt                 = "off"
  }
}

Expected output

For the refresh (and therefore the plan) to succeed.

Actual output

╷
│ Error: Error reading setting "aegis" for zone "[REDACTED]": Sorry, this zone setting is not available for your plan type. (1135)
│ 
│   with cloudflare_zone_settings_override.all["[REDACTED]"],
│   on cloudflare_zone.tf line 11, in resource "cloudflare_zone_settings_override" "all":
│   11: resource "cloudflare_zone_settings_override" "all" {
│ 
╵

Steps to reproduce

1. Create a cloudflare_zone_settings_override resource using a provider version prior to v4.50.0.
2. Upgrade to use the v4.50.0 version of the provider.
3. Plan (or just refresh).

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

[ricardbejarano]

I cannot share the full log, and there is no need to since this is easy to replicate.

[Hexide]

Our organisation is impacted too, currently we have about 260 terraform repositories affected by this bug.

[larivierec]

This happened also this morning.
Downgrading removes the issue.

[etekampe]

We've also ran into this issue and luckily are still running the previous version. Disabling aegis doesn't do anything at all:

resource "cloudflare_zone_settings_override" "settings" {
  zone_id    = cloudflare_zone.create_zone[each.key].id
  settings {
    aegis {
      enabled = false
    }
    // some other basic settings
  }
}

This doesn't seem to disable aegis so the plan keeps failing.

[sidick]

I get the same, no mention of aegis in my config and the issue is that the provider tries to read the state from the Cloudflare API which gets denied because I don't have it on my plan.

[jacobbednarz]

the service team have deployed a change to not error when not entitled.

[ricardbejarano]

Correct, this is now fixed. Thanks @jacobbednarz and service team!