### Terraform Version ```shell Terraform v1.9.8 on linux_amd64 + provider registry.terraform.io/cloudposse/utils v1.24.0 + provider registry.terraform.io/hashicorp/aws v5.55.0 + provider registry.terraform.io/hashicorp/external v2.3.3 + provider registry.terraform.io/hashicorp/local v2.5.1 ``` ### Terraform Configuration Files `backend.tf.json`: ```json { "terraform": { "backend": { "s3": { "assume_role": { "role_arn": "arn:aws:iam::123456789012:role/sl-automation-terraform" }, "bucket": "sl-atmos-tfstate-123456789012", "dynamodb_table": "sl-atmos-tfstate-lock-123456789012", "encrypt": true, "key": "terraform.tfstate", "region": "eu-central-1", "workspace_key_prefix": "wms//xe02/sandbox" } } } } ``` ### Debug Output - ### Expected Behavior `terraform workspace new -lock=false foo` should not try to lock the state. ### Actual Behavior `terraform workspace new -lock=false foo` fails if a DynamoDB lock is held by some other process. ### Steps to Reproduce There is probably an easier way to reproduce this but this is more or less what happened: On one host: 1. Use a non-`default` workspace (let's call it `foo`) 2. Start some long-running `apply` 3. Abort it in the middle by killing the process or just pressing Ctrl+C twice (the DynamoDB lock is not cleared) On another host: 1. Using the `default` workspace: Try to clean up the mess via `terraform force-unlock $uuid` (result: `Failed to unlock state: failed to retrieve lock info for lock ID "8ac7bbfc-c1b4-615d-38d7-f7ba634aa4bb": unexpected end of JSON input` because the wrong `LockID` is looked up according to the debug log) 2. Try to switch to a properly named workspace via `terraform workspace new foo`: This will fail due to the existing lock 3. Discover the `-lock=file` option and try it with `terraform workspace new -lock=false foo`: This will fail, too ### Additional Context _No response_ ### References - cloudposse/atmos#800