I’m getting the following error when running terraform f-chdir=cdktf.out/stacks/MY-STACK apply -auto-approve -lock=false.
╷
│ Error: Failed to save state
│
│ Error saving state: Error uploading state: Conflict
│
│ This workspace is not locked and will only accept state uploads
│ when locked
╵
╷
│ Error: Failed to persist state to backend
│
│ The error shown above has prevented Terraform from writing the updated
│ state to the configured backend. To allow for recovery, the state has been
│ written to the file "errored.tfstate" in the current working directory.
│
│ Running "terraform apply" again at this point will create a forked state,
│ making it harder to recover.
│
│ To retry writing this state, use the following command:
│ terraform state push errored.tfstate
│
╵
I’ve tried running terraform init -lock=false but there appears to be a lock on my workspace. How do I override that?
EDIT:
I think I misread the error message. I think it was saying that my Terraform Cloud workspace wasn’t locked so it couldn’t upload state until it is locked. Curious why this is the case though?
I’m following the guidance here to prevent state locking when running terraform in CI. Occasionally CI jobs will fail without releasing the lock and necessitate a manual removal of the lock before terraform can be run again (my team is using cdktf).
Instead of being handled by terraform, locking in CI is managed by our CI service provider. Is there a better way of doing this?
@stuart-c thank you. I’m using a Terraform Cloud workspace and it seems like locking is a feature that I can’t opt-out of using. Specifically it seems like the workspace actively prevents the use -lock=false when doing a terraform apply. Can you confirm that? I didn’t see anything in the docs about being able to not use locks but want to confirm.
I don’t use Terraform Cloud so I don’t know, but it sounds very sensible. The Terraform remote state locking is a very important safety feature to try to prevent corrupting the state file, so shouldn’t be being disabled regularly.
Indeed, the mechanism that -lock=false controls is whether the client will try to obtain a lock, but it doesn’t change anything about the server’s behavior and it still gets to enforce its own policy.
Because state-only storage backends are typically talking to systems that aren’t aware of Terraform there usually isn’t a server side policy for locking, and so the lock acts only as an advisory lock for cooperating clients. Any client that doesn’t take a lock can still potentially run operations, but no other client will be aware of it and so it’s possible that the state will become forked, which is difficult to recover from.
Terraform Cloud is a system designed specifically for Terraform and so it has policy and behavior of its own. A significant difference is that Terraform Cloud uses mandatory locks rather than advisory locks, in part because Terraform Cloud also maintains a queue of runs waiting to execute and the locking mechanism acts as the backpressure for that queue.