🚨 OpenTofu Error: 'Provider produced inconsistent final plan' — Cause, Fix, and Troubleshooting Guide

Overview

During tofu apply, OpenTofu asks the provider to produce a final plan for each resource and checks it against the proposed plan from tofu plan. If the provider returns a value that differs from what it promised — for an attribute that was not marked “known after apply” — OpenTofu aborts to protect you from silent drift:

Error: Provider produced inconsistent final plan

When expanding the plan for aws_instance.web to include new values learned so
far during apply, provider "registry.opentofu.org/hashicorp/aws" produced an
invalid new value for .metadata_options[0].http_protocol_ipv6: was
cty.StringVal(""), but now cty.StringVal("disabled").

This is a bug in the provider, which should be reported in the provider's own
issue tracker.

Symptoms

• tofu plan succeeds but tofu apply fails partway with Provider produced inconsistent final plan.
• The message names a specific resource and attribute, and usually says “This is a bug in the provider.”
• It is often intermittent — reruns sometimes pass once the resource exists.
• Frequently follows a provider upgrade or use of a newer resource attribute.

Common Root Causes

• Provider bug — the provider computed a different value than it declared during plan; this is the literal message and the most common cause.
• Stale provider version — an older provider had a defaulting bug fixed in a later release.
• Computed defaults — an attribute you left unset gets a server-side default the provider mishandles.
• Conflicting attributes — setting both a value and a computed block the provider cannot reconcile.
• Local state divergence — an out-of-band change made the refreshed value inconsistent with the plan.

How to diagnose

Identify the exact provider and attribute from the error, then check your provider version:

tofu version
tofu providers

Re-run with trace logging to capture the provider round-trip:

TF_LOG=trace tofu apply 2>&1 | tee /tmp/tofu-apply.log
grep -i "inconsistent" /tmp/tofu-apply.log

Check whether a newer provider release fixes the attribute in question:

grep -nA6 "required_providers" *.tf
tofu init -upgrade   # after loosening the constraint

Fixes

Upgrade the provider — the fix usually ships in a newer release:

# bump the constraint in required_providers, then:
tofu init -upgrade
tofu apply

Pin explicitly to a known-good version if the newest release regressed:

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "5.62.0"
    }
  }
}

Remove the offending attribute or let the provider default it, avoiding the value it cannot reconcile:

# instead of forcing http_protocol_ipv6 = ""
metadata_options {
  http_endpoint = "enabled"
}

Refresh and re-apply if the inconsistency came from drift:

tofu apply -refresh-only
tofu apply

What to watch out for

• The message literally says it is a provider bug — file it upstream with the resource/attribute and provider version.
• Pin providers so an accidental upgrade does not reintroduce the inconsistency in the middle of an apply.
• A partial apply may have created some resources; run tofu plan afterward to see remaining work.
• Do not paper over it with ignore_changes unless you understand the attribute — you may hide real drift.
• Reproduce with TF_LOG=trace before reporting so maintainers can see the plan/apply values.

Related

• OpenTofu Error: ‘Inconsistent dependency lock file’ — Cause, Fix, and Troubleshooting Guide
• OpenTofu Error: ‘Provider does not support resource type’ — Cause, Fix, and Troubleshooting Guide
• OpenTofu Error: ‘Objects have changed outside of OpenTofu’ — Cause, Fix, and Troubleshooting Guide