Skip to main content
DevOps Insightsguides & answers

Terraform · troubleshooting

Missing Resource Identity After Read

A provider release added or changed resource identity, and it reads your existing resources wrongly: no identity at all, or one that differs from state. It is a provider bug, usually fixed in the next release. Upgrade the provider; if the newest release still fails, pin the last version that worked.

First published

New to this? Read what is actually happening first, then come back to the steps.

On this page · 9 sections

Before you start

  • The full error, including the resource address and, for Unexpected Identity Change, the Current and New Identity values.
  • The provider version from terraform version, and the version that worked before, from your lock file's history.
  • Permission to change version constraints and commit .terraform.lock.hcl.

Run this first

step 1 of 2
terraform plan 2>&1 | grep -E 'Identity|with ' | sort | uniq -c | sort -rn | head

Look for Every failing address of the same type, such as aws_network_acl_rule

Shows which resource addresses fail and whether they share one resource type.

Work out which cause you have

A few questions to narrow the list. Every answer ends in a command that confirms or rules the cause out — this cannot see your cluster, so nothing here is a certainty until you have checked.

Narrow it down

0 answered · nothing is sent anywhere

Did the error start right after a provider upgrade, for every resource of one type?

Cause space

2 of 2 still possible

  • A provider release mishandles identity for one resource typeCommon
  • The object was deleted outside Terraform, and state predates identityOccasional

Nothing ruled out yet. Answer the question above and the branches your answer eliminates will strike through here.

Or diagnose it manually

In this order. The first command usually contains the whole answer.

  1. Step 1

    terraform plan 2>&1 | grep -E 'Identity|with ' | sort | uniq -c | sort -rn | head

    Shows which resource addresses fail and whether they share one resource type.

    Look for Every failing address of the same type, such as aws_network_acl_rule

  2. Step 2

    terraform version

    Names the provider version to look up in the provider's CHANGELOG and issues.

    Look for A release from the last few days

Every cause, and how to fix it

Ordered by how often each one turns out to be the answer.

A provider release mishandles identity for one resource type

Common

The newest provider added identity support, or changed it, for a resource type, and reads your existing resources of that type incorrectly. Every instance of that type fails the same way.

Confirm

terraform version
git log -p --follow -- .terraform.lock.hcl | grep -E '^[-+] *version' | head

A provider upgrade just before the errors began, and all failing resources of one type

Fix

  • Upgrade to the newest provider release with terraform init -upgrade: these regressions are usually fixed within days. Read the provider's CHANGELOG for the resource type.
  • If the newest release still fails, pin the last version that worked, for example version = ">= 6.0, != 6.59.0" or = 6.58.0, run terraform init -upgrade, and commit the lock file.
  • Search the provider's issues for the resource type and the message; if there is no report, open one with the error and both identities. The message is right that it is the provider's to fix.
terraform init -upgrade

Then plan. If it still fails, pin the last working version instead.

The object was deleted outside Terraform, and state predates identity

Occasional

A resource created with a provider older than its identity support has no identity in state. If the real object was then deleted in the console or by another tool, some releases failed with Missing Resource Identity After Read instead of planning to create it again.

Confirm

terraform state show ADDRESS

The resource in state, while the console or CLI shows the object no longer exists

Fix

  • Upgrade the provider; in the AWS case this was fixed in 6.37.0, after which the plan simply proposes to recreate the object.
  • If you meant to delete it, remove it from configuration as well so Terraform stops tracking it.

Understanding it properly

Skip this if you are mid-incident — the working part of the page is above. Worth reading afterwards, because understanding the mechanism is what stops the next one.

In plain terms

Since Terraform 1.12, providers can store an identity for each resource next to its settings in state: the few values that pin down exactly which real object it is, such as its name, account and region. The provider checks that identity every time it reads the resource. When a new provider release gets that check wrong for some resource type, every plan fails with one of these two messages, even though nothing in your configuration or your cloud account changed. The message itself says it is the provider's fault, and it is right.

Words used on this page

Resource identity
The minimal set of values that identifies a real object, stored in state since Terraform 1.12. It must not change while the object exists.
Missing Resource Identity After Read
The provider read the resource without an error but returned no identity, which its SDK refuses.
Unexpected Identity Change
The provider returned an identity different from the one in state, during a read, plan or update.
Lock file
.terraform.lock.hcl, which records the exact provider version; its git history shows which version last worked.
What is actually happening

Both messages come from the SDKs providers are built on (terraform-plugin-sdk and terraform-plugin-framework), not from your configuration. The check runs inside the provider, so it can appear with older Terraform versions too: one AWS report was on Terraform 1.7.5.

Missing Resource Identity After Read: the read succeeded but returned no identity. Typical trigger: a resource created before the provider supported identity for that type, so state has none, and a release that mishandles that case.

Unexpected Identity Change: the identity the provider computed differs from the stored one. In one AWS case the provider stored an SSM parameter name without its leading slash, then compared it with the real name.

In the AWS provider each of these was a single-release regression fixed within days: aws_network_acl_rule in 6.59.0 (fixed 6.60.0), aws_ssm_parameter in 6.58.0 (fixed 6.59.0), and resources deleted outside Terraform in 6.34.0 (fixed 6.37.0).

How to tell this is your problem
WhereWhat you see
terraform planError: Missing Resource Identity After Read: The Terraform provider unexpectedly returned no resource identity after having no errors in the resource read.
terraform plan or applyError: Unexpected Identity Change: During the read operation, the Terraform Provider unexpectedly returned a different identity then the previously stored one.
The same errorCurrent Identity: cty.ObjectVal(…) and New Identity: cty.ObjectVal(…), differing in one value
TimingStarts right after terraform init -upgrade or a provider bump; every resource of one type fails.

How to know it is actually fixed

  • terraform plan completes, with no changes if nothing else changed.
  • The lock file records the version you upgraded or pinned to, and it is committed.

Stopping it happening again

  • Commit .terraform.lock.hcl and upgrade providers in a pull request whose plan you read, not with -upgrade in every CI run.
  • Upgrade production stacks a few days after a provider release; identity regressions have been fixed within that window.

Security considerations

  • Back up state before any state command, and prefer upgrading or pinning the provider over editing state: removing and re-importing a resource by hand can attach the wrong real object.
  • Do not keep a pinned old provider forever to avoid the error; it stops receiving fixes. Put a date on the pin and follow the provider issue.

Sources

Behaviour described here is drawn from official documentation. Where a figure could not be confirmed on an official page it is attributed in the text rather than stated as canonical.

Did this get you to an answer?

No text box on purpose — please do not paste production logs anywhere

Something wrong or out of date? Report it

Where to go next