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

```text
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.
2. If it persists, identify the flapping attribute from the error and stop tracking it:
   ```hcl
   lifecycle {
     ignore_changes = [some_attr]
   }
   ```
   Expected: plan stabilizes; the attribute is left alone after creation.
3. 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.
4. 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.