Repository navigation
Provider 5.23.0 fails on cloudflare_email_routing_settings plan #7304
Description
Activity
- addedkind/bugCategorizes issue or PR as related to a bug.Categorizes issue or PR as related to a bug.needs-triageIndicates an issue or PR lacks a `triage/foo` label and requires one.Indicates an issue or PR lacks a `triage/foo` label and requires one.
on Aug 11, 2026 - removedneeds-triageIndicates an issue or PR lacks a `triage/foo` label and requires one.Indicates an issue or PR lacks a `triage/foo` label and requires one.
on Aug 18, 2026 Thank you for submitting an issue! This issue has been flagged for an internal Cloudflare team to take a look. If this is urgently blocking your development or deployment, please open a support case so we can serve you faster.
I see that this problem also exists in provider version 5.24.0. @jessicayingg
Reacted by Kyle Berry and Peter ParenteStill reproducing on 5.25.0.
I saw
support_subaddresslisted under "New Attributes" in the 5.25.0 release notes and hoped this was the fix, but the attribute was added tocloudflare_email_routing_dns— notcloudflare_email_routing_settings. This resource is still broken.Confirmed with a plan against 5.25.0 today (Terraform v1.15.9):
Error: Value Conversion Error with cloudflare_email_routing_settings.mollercloud_no An unexpected error was encountered trying to convert tftypes.Value into email_routing_settings.EmailRoutingSettingsModel. This is always an error in the provider. Please report the following to the provider developer: mismatch between struct and object: Struct defines fields not found in object: support_subaddress.Identical failure to 5.23.0 and 5.24.0.
Root cause
At tag
v5.25.0the resource model and the resource schema disagree.internal/services/email_routing_settings/model.godeclares the field:SupportSubaddress types.Bool `tfsdk:"support_subaddress" json:"support_subaddress,optional"`
internal/services/email_routing_settings/schema.godoes not —ResourceSchemaonly definesid,zone_id,created,enabled,modified,name,skip_wizard,statusandtag.Every
tfsdkfield on the struct needs a matching schema attribute, so the conversion fails on every plan/refresh.Worth noting the data source pair is consistent — neither
data_source_model.gonordata_source_schema.gohassupport_subaddress— so the drift looks isolated to the resource: the resource model picked up the new API field butResourceSchemawasn't regenerated alongside it.Suggested fix
Add the matching attribute to
ResourceSchema:"support_subaddress": schema.BoolAttribute{ Description: "Whether plus-addressing is honored when matching routing rules.", Optional: true, },
…or drop the field from the model if it isn't meant to be exposed on this resource yet.
This is still present on
mainas of today —schema.gothere is byte-identical to the v5.25.0 one (blob76022b78).This blocks us from upgrading the provider past 5.22.0 at all, since the error fires on plan for any config containing this resource. 🙏
- added a commit that references this issue
on Sep 15, 2026 Can you have a look at my fix suggestion @jessicayingg @jhutchings1 ? Two new versions and no fix.
Resolved in 5.26.0 — thanks @rotem-cloud for picking this up (
APIX-1508).Verified on Terraform v1.16.3 / provider v5.26.0: the
Value Conversion Errorreported here is gone.terraform plancompletes against a config containingcloudflare_email_routing_settings, which has been impossible since 5.23.0. Closing.For anyone arriving from a search: the schema fix that resolved this is in
f5f3e69.
One caveat for anyone upgrading straight to 5.26.0: the fix unblocks plan, but apply then fails for configs that omit
support_subaddress:Error: Provider produced inconsistent result after apply .support_subaddress: was null, but now cty.FalseThe attribute was added as
OptionalwithoutComputed, so Terraform plansnullwhile the API returnsfalse. I've filed that separately as #7393 rather than reopening here, since it's a distinct defect at a different phase — this issue was a schema/model mismatch breaking value conversion; that one is a plan/apply consistency violation.Related: #7386 covers the write path (
Createomits the attribute,Updateis a stub), sosupport_subaddressis not yet settable even once the consistency error is fixed. #7393 and #7386 together cover what's left.Workaround until then:
resource "cloudflare_email_routing_settings" "example" { zone_id = var.zone_id lifecycle { ignore_changes = [support_subaddress] } }


Confirmation
Terraform and Cloudflare provider version
Trying to update from provider 5.22.0 to 5.23.0 plan fails on the same code:
Error: Value Conversion Error
with cloudflare_email_routing_settings.mollercloud_no
An unexpected error was encountered trying to convert tftypes.Value into email_routing_settings.EmailRoutingSettingsModel. This is always an error in the provider. Please report the following to the provider developer:
mismatch between struct and object: Struct defines fields not found in object: support_subaddress.
Affected resource(s)
cloudflare_email_routing_settings
Terraform configuration files
Link to debug output
Panic output
No response
Expected output
No plan error
Actual output
{"@Level":"error","@message":"Error: Value Conversion Error","@module":"terraform.ui","@timestamp":"2026-08-08T23:24:21.827965Z","diagnostic":{"severity":"error","summary":"Value Conversion Error","detail":"An unexpected error was encountered trying to convert tftypes.Value into email_routing_settings.EmailRoutingSettingsModel. This is always an error in the provider. Please report the following to the provider developer:\n\nmismatch between struct and object: Struct defines fields not found in object: support_subaddress.","address":"cloudflare_email_routing_settings.mollercloud_no"},"type":"diagnostic"}
Operation failed: failed running terraform plan (exit 1)�
Steps to reproduce
Additional factoids
No response
References
No response