Enable to set `Who` in a state lock

[sato-s]

Terraform Version

1.14.0

Use Cases

If we have a conflicting lock, terraform shows the following message.

Error message: writing "[somewhere].tflock"
failed: googleapi: Error 412: At least one of the pre-conditions you
specified did not hold., conditionNotMet
Lock Info:
  ID:        8888888888888888
  Path:      [somewhere]
  Operation: OperationTypeInvalid
  Who:       user@hostname
  Version:   1.14.0
  Created:   2025-09-26 03:05:44.03612 +0000 UTC
  Info:      

We can check this conflicting lock by contacting with a Who of that message. But if terraform is triggered by CI, we can't contact with Who. Because, user of Who is a user name of host computer that runs CI. https://github.com/hashicorp/terraform/blob/a4cc769e5bea770aa5cdb5d726a3fe401f906c71/internal/states/statemgr/locker.go#L161

If we can configure Who, we can configure CI to use that variable to indicate the person who is responsible for the state lock.

Attempted Solutions

We can't configure Who since it's fixed to os user name. https://github.com/hashicorp/terraform/blob/a4cc769e5bea770aa5cdb5d726a3fe401f906c71/internal/states/statemgr/locker.go#L161

Proposal

Enable to set a user of Who by introducing environment variable like TERRAFORM_LOCK_USER.

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!

[radeksimko]

I don't want to go into any details as to how exactly, when and whether this would be implemented but wanted to share some thoughts while they are fresh in my head. 😄

The CI use case for me provokes a question of why the CI doesn't do some form of token based impersonation based on who triggered the job if it's that important to know which exact human is behind the CI run. I appreciate this may me a bigger project to set it up that way but I think that would best align with the needs that there seem to be and also allow you to restrict what exactly each human can and cannot do with their token, rather than have a single token for the CI pipeline.

Aside from that, I can imagine Terraform allowing end-user to set some additional metadata but not to replace it, as the issue wording originally proposes. i.e. The lock information should as a whole be able to still convey that it is lock held by CI, and maybe also that the CI run was triggered in a specific context.

[PT-GD]

Some sort of intelligence around the "WHO" is useful. For example, GitHub codespaces give you a username of "codespace," however the context of "who"-ness can be derived from such things as the GITHUB_USER environment variable.

It would be great to "hint" Terraform with a who other than some generic container username.