Error: Provider produced inconsistent final plan: "produced an invalid new value" after apply

TL;DR

During apply, the provider returned a value that contradicts what it planned. Terraform treats this as a provider bug, and the error message says so. Your move: upgrade the provider (the bug is often already fixed), and if it persists, file it on the provider's issue tracker with the exact was ... but now ... lines.

The error

Error: Provider produced inconsistent final plan

When expanding the plan for aws_ecs_task_definition.api to include new
values learned so far during apply, provider
"registry.terraform.io/hashicorp/aws" produced an invalid new value for
.container_definitions: inconsistent values for sensitive attribute.

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

Steps to fix

1. Read the was ... but now ... (or equivalent) detail: it names the attribute whose planned and apply-time values disagree.

• Expected: you know which attribute the provider mishandled.

1. Upgrade the provider to the latest version: loosen or bump the version constraint, run terraform init -upgrade.

• Expected: a newer provider contains the consistency fix; re-run apply.

1. If the latest provider still fails, work around by making the planned value match reality: e.g. for sensitive-attribute mismatches, ensure the configuration value is exactly what the API returns (no extra whitespace or reordering in JSON documents).

• Expected: plan and apply agree on the value.

1. File the issue on the provider's tracker with the full error text, provider version, and a minimal config.

• Expected: maintainer can reproduce from your report.

When to use this

• terraform apply fails with Provider produced inconsistent final plan while plan succeeded. The state is usually still written, so a second apply may look clean.

When NOT to use this

• Provider produced inconsistent result after apply is the sibling error for the post-apply read-back check; the triage is the same but the trigger differs. If your config changed between plan and apply, that is on you, not the provider.

Compatibility

• Terraform 0.15+ (the final-plan consistency check). Provider-side; seen across AWS, Vault, Equinix, vSphere providers.

Root cause

Providers must return values during apply that are consistent with the plan they produced. When a provider normalizes, drops, or reorders a value between plan and apply (sensitive attribute handling, API defaults, JSON canonicalization), Terraform's consistency check fails the apply rather than recording a value it never planned.

Edge cases

• ignore_changes on the flapping attribute can silence it, but it also blinds you to real drift; prefer the provider upgrade.
• JSON policy documents are the classic trigger: semantically identical but textually different documents trip the check. Normalize with jsonencode of a decoded value.
• The error aborts the apply but state is usually saved; inspect terraform plan after before re-running.