`terraform workspace new -lock=false` doesn't work as advertised

[mss]

Terraform Version

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:

{
  "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

[bschaatsbergen]

Hey @mss,

Thank you for reporting this! The S3 backend is managed by the AWS Provider team at HashiCorp, and this issue has been added to their triage queue. Are you able to confirm that you're only experiencing this with the S3 backend? Thanks!

[mss]

@bschaatsbergen thanks for the quick follow-up. I don't have access to any other backend which supports locking so can't check if the flag doesn't work generally or is just not hooked up properly in the S3 backend.

[crw]

Based on the debug log provided, this looks like an issue with the S3 backend specifically.