Thanks for filing the request. Just to provide a quick answer for why we can’t immediately implement this; the way the remote state backend code is structured, remote state implementations can still write to their underlying storage when requesting access to a state, even if it’s not writing the terraform state itself. For this reason, internally when locking is possible, the implementation must take the lock to update the storage structures.
Another type of consideration is that if an apply is happening concurrently to the plan operation, the plan may show partially or fully invalid results. Now if this plan is saved, it could of course not be applied since the state would not match the new changes, but the result would be confusing to users who are assuming only one operation can happen at a time.
We are however working on restructuring remote state storage in general, and specifying all the requirements and details around locking of state storage will be part of that project. Once the new specification for remote state locking is defined, it will likely guide any changes to how state is locked in the CLI.
2 Likes