terraform force-unlock without having to specify lock ID

[red8888]

Terraform Version

Terraform v1.9.5
on darwin_arm64
+ provider registry.terraform.io/hashicorp/google v7.19.0
+ provider registry.terraform.io/hashicorp/google-beta v7.19.0

Use Cases

I want to just run a command to unlock the current state without having to copy/paste the lock ID terraform spits out after running a plan.

Attempted Solutions

There isn't even a way to programmatically get the lock ID to pass it to terraform force-unlock -force which is annoying.

Proposal

This is a convenience feature. Its annoying to have to copy the lock id and pass it to force-unlock. there should be a toggle to just unlock the current state without asking for a lock ID.

This could be a separate toggle or just add this to the force switch.

Terraform knows what the lock ID is so why can't terraform force-unlock -force just unlock the current state for me?

References

No response

[crw]

Thanks for this feature request! If you are viewing this issue and would like to indicate your interest, please use the 👍 reaction on the issue description to upvote this issue. We also welcome additional use case descriptions. Thanks again!

[apparentlymart]

This command has been largely unchanged for almost a decade so I'm not 100% sure I'm remembering right, but FWIW I believe that the original design intention here was to ensure that the operator is unlocking the lock they think they are unlocking.

Without that, in theory two people working concurrently could try to steal the same lock, in which case one of them would steal the lock from the other one's actually-running process. By requiring the lock id to be specified and checking whether it matched, there's more chance for Terraform to be able to detect that mistake and not silently steal the wrong lock. (Still not guaranteed of course, because someone could just copy the wrong lock id out of the error message and get into the same situation. This is more about reducing the impact of mistakes than preventing them completely.)

I'm not sharing this to say that the design shouldn't change here. Just mentioning it in case it's helpful in deciding what to do in response to this feature request.

[jbardin]

Yes, that tracks with the original intent of the command. I'd also add that besides the requirement that only a specific lock be released if possible, the other aspect was that force-unlock was never intended to be a normal part of the workflow. It's only designed to recover in exceptional cases when faced with an unexpected failure, so the explicitness of the command was considered a benefit at the time.
This type of locking is a distributed systems problem, so as an example:

1. A backend can use timed leases for locks, which is not exposed to the user
2. A failure occurs leaving a lease in place
3. A user runs force-unlock without a valid ID, but in the meantime the lease expired
4. A new process took up the lock with a new lease, which gets revoked by the command in step 3, causing a failure to store any new changes to the state