Error: Provider produced an inconsistent final plan

TL;DR: This is a provider bug, not your HCL: the provider promised one value at plan time and produced another at apply time. Upgrade the provider first (tofu init -upgrade); if it persists, quarantine the flapping attribute with ignore_changes.

Error: Provider produced an inconsistent final plan

... produced an invalid new value for . some_attr ...

Steps

1. Upgrade the provider: tofu init -upgrade, then re-run.

Expected: frequently fixed, since these get patched upstream.

1. If it persists, identify the flapping attribute from the error and stop tracking it:

   lifecycle {
     ignore_changes = [some_attr]
   }

Expected: plan stabilizes; the attribute is left alone after creation.

1. Last resort: tofu apply -replace=[address] to force a clean recreate so the provider computes the attribute fresh.

Expected: the replacement plans and applies consistently.

1. If it STILL persists, file an upstream issue with the provider including the plan/apply diff.

Expected: maintainer can reproduce the plan/apply divergence.

When this applies

• Provider produced an inconsistent final plan naming a specific attribute.
• The config is valid and the value is provider-computed.

When it doesn't apply

• Provider produced inconsistent result after apply: the sibling error; same family, but this one fires when the final PLAN (not the apply result) diverges.
• Inconsistent conditional result types: that's your expression, not the provider.

Tool versions

All OpenTofu versions.

Why it happens

Providers promise planned values for computed attributes, then compute them for real at apply. If the provider's plan-time logic and apply-time logic disagree (often a normalization or defaulting bug), tofu catches the divergence and fails rather than writing a state it can't explain.

Edge cases

• ignore_changes on the flapping attribute means drift there goes undetected; document why it's there so nobody "cleans it up".
• Don't confuse with Provider produced inconsistent result after apply when searching provider issue trackers; they're reported separately upstream.