chore: update lock message

[bodinsamuel]

I have encountered an issue today with a connectivity lost that happened to let the lock in a bad state. The message was helpful enough to make me understand this but not how to unlock, and I figured because you mention "-lock=false" there was no other command available. But actually there is another command. Maybe it was intentional to not mention it, but as you are already mentioning a way to bypass the lock it's even better to displays to correct solution.

Not putting the -force intentionally so that people still get the confirmation by copy/pasting.

I also think it could be highlighted in white and maybe with the LOCK_ID prefilled for convenience, but my skills in go stop there :D

[hashicorp-cla]

Thank you for your submission! We require that all contributors sign our Contributor License Agreement ("CLA") before we can accept the contribution. Read and sign the agreement

Learn more about why HashiCorp requires a CLA and what the CLA includes

---

Samuel Bodin seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.

_{Have you signed the CLA already but the status is still pending? Recheck it.}

[bodinsamuel]

Forgot about this one. Any feedback @apparentlymart ☺️

[crw]

Just FYI @laurapacilio this is a change to the CLI help doc. I do not know if this information was purposefully excluded from the CLI help doc.

[laurapacilio]

Hi @bodinsamuel - Thank you so much for submitting this! I talked to engineering, and here's a summary of our thoughts:

• When we put full commands in the CLI help text that users can copy and paste, the assumption is that a lot of folks will do that automatically (kind of like when git gives you the commands to automatically push to a remote branch, etc.). We usually hesitate to do this because we wouldn't want folks to automatically take an action without fully understanding the implications.
• However, we do think the points you raised are valid, and so we think the right approach is to write something like: "If a previous unlock operation failed, you can use the "terraform force-unlock" command to override the lock." This approach intentionally leaves out the LOCK_ID part. The rational is that if the user copies that directly and tries to run it, they'll get the usage messages for the "force-unlock" command (LOCK_ID is a required argument). We can then use those messages to give a bit more information about the consequences of this action.

All of this to say - would you be open to modifying your edits to remove the LOCK_ID portion and just reference the "force-unlock" command? Let me know your thoughts, and thank you again for the suggestion! :-)

[crw]

@bodinsamuel thanks for this contribution! Do you have any feedback regarding the above comment? Thanks again for this contribution, we appreciate it!

[vercel[bot]]

@bodinsamuel is attempting to deploy a commit to the HashiCorp Team on Vercel.

A member of the Team first needs to authorize it.

[bodinsamuel]

Oops sorry for the lag, I had completely forgotten about this. I understand your points totally make sense, I have removed the LOCK_ID. Feel free to modify my PR and merge/close if needed ☺️