## 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
1. Verify the destroy actually worked: check that the resources are gone (AWS console, or re-run `cdktf diff` and confirm no state).
2. If everything is deleted, no action needed; the error is expected.
3. 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 destroy` ends 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.