a0deploy import error deleted resources not removed fails

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.

Not specified by the original author.

TL;DR

The import ID you gave does not match any real object the provider can see. Either the ID is wrong, the provider is pointed at the wrong region/account/endpoint, or the object was already deleted. Verify the object exists with the provider's CLI, fix the ID or provider config, and retry the import.

The error

Error: Cannot import non-existent remote object

While attempting to import an existing object to "module.sql_server.azurerm_mssql_server.SqlServer",
the provider detected that no object exists with the given id. Only pre-existing
objects can be imported; check that the id is correct and that it is associated
with the provider's configured region or endpoint, or use "terraform apply" to
create a new remote object for this resource.

Steps to fix

1. Verify the object exists independently of Terraform, e.g. aws ec2 describe-instances --instance-ids [id] or the cloud console.

   • Expected: you confirm whether the object is really there.

2. Check the import ID format against the provider docs: many resources need full ARNs or compound IDs, not short names.

   • Expected: your ID matches the documented import format.

3. Check the provider configuration Terraform used: region, profile, endpoint, subscription. A correct ID in the wrong region reads as non-existent.

   • Expected: provider points at the same place the object lives.

4. Fix the import block's id (or the terraform import argument) and re-run plan.

   • Expected: import proceeds to the refresh step.

When to use this

• terraform plan with an import block, or terraform import, fails with Cannot import non-existent remote object.

When NOT to use this

• Invalid resource instance data in state is a provider-version/state decoding problem, not a missing object. If the object genuinely does not exist and you want it, remove the import block and let apply create it.

Compatibility

• Import blocks: Terraform 1.5+. terraform import CLI: all versions. Behavior is provider-driven.

Root cause

Import asks the provider to read an existing remote object by ID. If the read returns not-found (wrong ID format, wrong region/account, deleted object, or eventual-consistency lag after creation), the provider reports it and Terraform aborts rather than creating something the config did not ask for.

Edge cases

• Right after creating an object out-of-band, retry: some APIs are eventually consistent.
• Cross-account/assume-role setups: the ID may exist in an account your credentials cannot see.
• for_each imports need one import block per instance key; a single block with a wrong key fails the same way.

hashicorp/terraform-provider-aws#26883 is a real instance of this failure mode, and a HashiCorp Discuss thread on azurermmssqlserver import shows the full verbatim error: "Error: Cannot import non-existent remote object. While attempting to import an existing object to \"module.sqlserver.azurermmssql_server.SqlServer\", the provider detected that no object exists with the given id. Only pre-existing objects can be imported; check that the id is correct and that it is associated with the provider's configured region or endpoint, or use \"terraform apply\" to create a new remote object for this resource."

Not specified by the original author.

Short answer: the deployment your request points to does not exist. Open the project in the Vercel dashboard, copy the live deployment URL from there, and use that exact URL. `` DEPLOYMENT_NOT_FOUND `` 1. In the Vercel dashboard, open the project and confirm the deployment still exists. Deleted deployments and preview deployments from removed branches are gone for good. 2. Copy the deployment URL exactly from the dashboard and compare it character by character with the one you requested. Fix typos, stale IDs, or wrong paths. 3. If the deployment exists but will not load, open its build and runtime logs. A failed build leaves no servable output, and the logs show why. 4. Confirm your account still has permission to access the project. A lost or changed role produces the same not-found. Root cause: Vercel resolves the deployment reference before it resolves any route inside it. A bad reference fails at that first step, so no application code ever runs. When to use: API calls, webhooks, or browser hits that name a specific deployment and get this code. When NOT to use: 404s on routes inside a working deployment are routing problems, check rewrites in vercel.json, not the deployment reference. Variant phrasings: "vercel deployment not found error", "vercel 404 deploymentnotfound", "deployment not found vercel preview". Edge cases: preview URLs die with their branches. If you linked a preview URL somewhere durable, promote a production deployment and link that instead.

Context: DEPLOYMENTNOTFOUND is Vercel's 404 for a deployment reference. It fires when a request names a deployment that does not exist: the URL or deployment ID has a typo, points at a stale preview, or the deployment was deleted. It is about the deployment itself, not about a page inside your app.

Source: DEPLOYMENTNOTFOUND is Vercel's 404 for a deployment reference. It fires when a request names a deployment that does not exist: the URL or deployment ID has a typo, points at a stale preview, or the deployment was deleted. It is about the deployment itself, not about a page inside your app.

Verified resolution: Short answer: the deployment your request points to does not exist. Open the project in the Vercel dashboard, copy the live deployment URL from there, and use that exact URL. `` DEPLOYMENT_NOT_FOUND `` 1. In the Vercel dashboard, open the project and confirm the deployment still exists. Deleted deployments and preview deployments from removed branches are gone for good. 2. Copy the deployment URL exactly from the dashboard and compare it character by character with the one you requested. Fix typos, stale IDs, or wrong paths. 3. If the deployment exists but will not load, open its build and runtime logs. A failed build leaves no servable output, and the logs show why. 4. Confirm your account still has permission to access the project. A lost or changed role produces the same not-found. Root cause: Vercel resolves the deployment reference before it resolves any route inside it. A bad reference fails at that first step, so no application code ever runs. When to use: API calls, webhooks, or browser hits that name a specific deployment and get this code. When NOT to use: 404s on routes inside a working deployment are routing problems, check rewrites in vercel.json, not the deployment reference. Variant phrasings: "vercel deployment not found error", "vercel 404 deploymentnotfound", "deployment not found vercel preview". Edge cases: preview URLs die with their branches. If you linked a preview URL somewhere durable, promote a production deployment and link that instead.

Source URL: https://vercel.com/docs/errors/deploymentnotfound