cdktf destroy reports "failed to retrieve lock info" after deleting the state backend
Explains the expected failed-to-retrieve-lock-info error when cdktf destroy deletes the S3 bucket and DynamoDB table that held the state lock, and why it is safe to ignore. Use when destroy succeeds but ends with the lock info error. Not for lock contention during deploy.
TL;DR
Ignore it. When CDKTF manages the remote backend, cdktf destroy deletes the DynamoDB lock table along with everything else, so the final lock check fails. The destroy itself succeeded.
The error
After cdktf destroy completes, you see an error message saying failed to retrieve lock info.
Fix it
- Verify the destroy actually worked: check that the resources are gone (AWS console, or re-run
cdktf diffand confirm no state). - If everything is deleted, no action needed; the error is expected.
- If resources remain, the destroy genuinely failed; read the earlier output for the real error.
Expected result: all stack resources (and optionally the backend bucket/table) are deleted.
When to use this
cdktf destroyends with "failed to retrieve lock info" but resources are gone- You let CDKTF manage the S3 backend bucket and DynamoDB table
When NOT to use this
- Deploy/plan fails with a lock error while the table still exists (that is real lock contention; use force-unlock)
- Resources were not actually deleted
Root cause
Terraform checks the state lock after operations. When the stack itself provisions the backend (S3 bucket + DynamoDB table) and destroy removes them, the post-destroy lock lookup targets a table that no longer exists, producing the error. It is cosmetic.
Edge cases
- If you want a clean destroy log, manage the backend outside the stack (answer "no" to backend management) so the table survives.
Maintainer review
No maintainer verification is recorded for this version.
This records the version a maintainer checked. It does not assert that the version is the latest upstream release.