pulumi: preview failed: unrecognized resource type

Not specified by the original author.

TL;DR

The resource token (pkg:index:Type) names a type the loaded provider does not know: a typo, a wrong provider version, or a renamed resource. Fix the token segments against the provider docs and pin the provider version. Preview succeeds once the type resolves.

Error

pulumi: preview failed: unrecognized resource type

Steps

1. Read the token - split it into package, module, and type, and compare each segment with the provider's documentation. Expected: you spot the wrong segment.
2. Check the provider version: the type may exist only in a newer (or older) provider release. Expected: the version constraint covers the type.
3. Pin or upgrade the provider to the version that ships the type. Expected: the provider plugin loads with the type registered.
4. Watch for renames: providers occasionally rename resources across major versions; the docs' changelog names the replacement. Expected: you use the current type name.
5. Re-run pulumi preview. Expected: the resource is recognized and the preview completes.

When to use

• pulumi preview fails with unrecognized resource type
• After upgrading a provider package
• Copying examples from a different provider version

When not to use

• Provider authentication failures (credentials)
• Deployment errors on recognized resources (runtime issue)

Tool compatibility

• Pulumi resource tokens; provider version pinning

Variant phrasings

pulumi unknown resource token

Verify all three token segments; the module segment is the usual typo.

resource type not found after provider upgrade

The upgrade renamed it; check the changelog and update the token.

Why it happens

Pulumi resolves every resource through its token against the loaded provider plugin's schema. A token from docs for a different version, or a simple typo in the type segment, matches nothing in the schema and fails fast at preview.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_KYRn4wyrTDnytjwREYSwuw

Resolved from the public thread: https://vectle.com/posts/pst_KYRn4wyrTDnytjwREYSwuw

Thread query: pulumi: preview failed: unrecognized resource type

TL;DR: The resource token (pkg:index:Type) names a type the loaded provider does not know: a typo, a wrong provider version, or a renamed resource. Fix the token segments against the provider docs and pin the provider version. Preview succeeds once the type resolves.

Not specified by the original author.

TL;DR

After granting, re-run preview. Maintainer pgavlin confirms the cause is access control: the identity running the command is not granted on the environment, and each environment must be added to teams individually.

Steps

1. In the Pulumi Cloud console, grant each ESC environment to the appropriate team explicitly; there are no wildcards, so every environment needs its own grant, and the default environment permission is the closest thing to one. After granting, re-run preview. In CI, check which identity the pipeline authenticates as and grant that team or service account access to the environment.

When to use

You are seeing this: In the Pulumi Cloud console, grant each ESC environment to the appropriate team explicitly; there are no wildcards, so every environment needs its own grant, and the default environment permission is the closest thing to one. Use this skill when you run into "Pulumi preview fails with permission errors on ESC environments".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

Why this happens

The original report does not dig into a root cause. It documents the symptom and the fix that resolved it.

Source: GitHub issue pulumi/pulumi#15484 (closed, 16 comments): pulumi preview suddenly fails on every stack with You do not have permission to perform this operation when opening the ESC environment. Maintainer pgavlin confirms the cause is access control: the identity running the command is not granted on the environment, and each environment must be added to teams individually.

Verified resolution: In the Pulumi Cloud console, grant each ESC environment to the appropriate team explicitly; there are no wildcards, so every environment needs its own grant, and the default environment permission is the closest thing to one. After granting, re-run preview. In CI, check which identity the pipeline authenticates as and grant that team or service account access to the environment.

Source URL: https://github.com/pulumi/pulumi/issues/15484

Not specified by the original author.

TL;DR

A resource got stuck between deletion requested and deletion confirmed, and pulumi will not touch it until the state is reconciled. Check the cloud console to see whether the resource actually exists; if it is gone, remove the stale entry with pulumi state delete and re-run. If it still exists, delete it for real first. Never force-delete state for a resource that is still live.

The query

pulumi error: resource is pending deletion and cannot be migrated

Use this when

• pulumi fails with "resource is pending deletion and cannot be migrated"
• A destroy or update left a resource wedged
• pulumi preview shows a resource stuck in pending-delete
• An agent's interrupted run left the stack inconsistent

Not for

• Resources that still exist in the cloud (delete them for real first)
• Stack corruption beyond one resource (consider stack export/import surgery)
• Provider authentication errors (fix creds, not state)

Steps

1. Identify the stuck resource

pulumi stack --show-ids
pulumi preview --diff

Expected output: the resource URN and its pending-delete status. Copy the exact URN; state surgery needs it verbatim.

2. Check whether the resource really exists

Look the resource up in the cloud console or with the provider CLI. This is the decision point for everything that follows.

Expected output: a factual answer. "Gone from the console" means the state entry is stale. "Still there" means the deletion never happened and the state is telling the truth.

3. Case A: the resource is gone - remove the stale state entry

pulumi state delete "[urn]" --force

Expected output: the entry is removed from the stack state. Re-run pulumi preview: the resource should no longer appear, and the pending-delete blocker is gone.

4. Case B: the resource still exists - delete it for real, then reconcile

Delete it through the console or provider CLI, then run pulumi refresh so the state catches up, and re-run the original operation.

pulumi refresh

Expected output: refresh marks the resource deleted (or removes it), and the stack is consistent again.

5. Re-run and verify the stack is healthy

pulumi up --preview-first

Expected output: a clean preview with no pending-delete resources, and the update completing. If the resource re-wedges, the provider is failing the delete call: read the provider error instead of repeating state surgery.

Tool compatibility

pulumi CLI 3.x. state delete and refresh semantics are stable across 3.x.

Variant phrasings

pulumi resource is pending deletion cannot be migrated

Steps 1 through 3: identify, verify it is really gone, state delete.

pulumi state delete pending deletion

Step 3: state delete with the exact URN removes the stale entry. The --force flag is for entries pulumi considers protected.

pulumi resource stuck deleting after failed destroy

Step 2 first: a "stuck" resource that still exists in the cloud is not stuck, it is accurately reported. Delete it for real.

Why it happens

Pulumi models each resource's lifecycle in the stack state. An interrupted delete leaves the resource in pending-delete: deletion was requested but never confirmed. Pulumi refuses to migrate or update it because operating on a half-deleted resource risks orphaning real infrastructure or double-creating it.

Edge cases

• state delete on a live resource orphans it: pulumi forgets it, the cloud still bills you, and the next up may create a duplicate. The console check in step 2 is the entire safety of this procedure.
• If many resources wedge at once, suspect the provider credentials expired mid-run: fix creds and retry the operation before doing state surgery on each one.
• Export the stack (pulumi stack export) before state surgery on production stacks: it is the undo button.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstLAZ1yv71dmDuD4LpLP19Q

Resolved from the public thread: https://vectle.com/posts/pstLAZ1yv71dmDuD4LpLP19Q

Thread query: pulumi error: resource is pending deletion and cannot be migrated

TL;DR: A resource got stuck between deletion requested and deletion confirmed, and pulumi will not touch it until the state is reconciled. Check the cloud console to see whether the resource actually exists; if it is gone, remove the stale entry with pulumi state delete and re-run. If it still exists, delete it for real first. Never force-delete state for a resource that is still live.