A CI job was killed mid-apply and every Terraform run since fails with 'Error acquiring the state lock'. How do you clear it, and what must you verify before running terraform force-unlock?

## Read the lock before you break it A held lock is not an obstruction to clear reflexively; it is a claim by another run, with the evidence attached: ``` Error: Error acquiring the state lock Lock Info: ID: 4f2c9c17-9a6d-4c94-a09b-0e4a0dd9e0b5 Path: example-tfstate/prod/network/terraform.tfstate Operation: OperationTypeApply Who: runner@ci-7f4b Created: 2026-03-04 10:12:41 UTC Version: 1.11.2 ``` Four fields drive the decision. `Operation` tells you whether real changes were in flight (`OperationTypeApply`) or only a refresh (`OperationTypePlan`) — an abandoned plan lock is nearly always safe to clear, an apply lock deserves care. `Who` names the machine and user. `Created` tells you how long it has been held: three minutes into a fifteen-minute apply is a very different situation from eleven hours. `ID` is the argument you will need. ## Prove the holder is dead This is the one verification the question is really about. Locks do not time out on their own for the common object-store backends — Terraform releases the lock when the run ends, so a process killed with SIGKILL, an evicted container, a runner that lost its host, or a laptop that closed mid-apply leaves the record behind forever. Nothing expires it for you. So establish death positively, not by assumption: - Find the CI run that matches `Who` and `Created` and confirm it reached a terminal state. "The job page shows cancelled" is good evidence; "nobody replied in chat" is not. - If it was a human, ask them. A colleague halfway through a fifteen-minute apply is the classic case where the timestamp looks stale but the run is alive. - If you can, look at the infrastructure: a still-running apply is making API calls, so recent CloudTrail activity from the CI role, or a resource visibly mid-creation, argues the run lives. - Never use elapsed time alone as proof. Long applies exist. "It has been an hour, it must be dead" is precisely how a lock gets broken on a live run. ## Break it correctly ```bash terraform force-unlock 4f2c9c17-9a6d-4c94-a09b-0e4a0dd9e0b5 ``` Run it from the same working directory, after `terraform init` against the same backend configuration and the same workspace — force-unlock acts on the state your configuration points at, so running it from the wrong directory either errors or, worse, unlocks a different state. Terraform prompts for confirmation; `-force` skips the prompt and is for scripts, not for hurrying. The ID must match the held lock. That mismatch check is a safety feature: if the ID you pass is not the one currently held, Terraform refuses, which is what stops you from clearing a *newer* lock taken by a healthy run that started while you were investigating. Deleting the backing object by hand — removing the DynamoDB item or the `.tflock` object — does the same thing with none of those checks. Keep it as a genuine last resort, for example when the recorded lock ID has been lost or the backend is in a state force-unlock cannot address. ## What force-unlock does not do It deletes a lock record. That is all. It does not roll back partial changes, does not resume the dead apply, and does not repair state. The dead run may have created resources and died before persisting them, in which case state is behind reality. When an apply cannot write state to the backend at all, Terraform writes the result locally as `errored.tfstate` and tells you to push it — on a CI runner that file usually dies with the container, which is another reason a crashed apply needs a plan afterwards rather than a re-run on faith. So the sequence is: verify, unlock, then `terraform plan` and *read it*. Expect creations of things that already exist (state missed them), or no changes at all (the apply had finished its work and died during cleanup). Reconcile before re-applying — a blind re-apply after a crash is how duplicate resources get made. ## If you break a live lock Both runs now mutate the same infrastructure. They will issue conflicting API calls, and both will try to persist state at the end. One write lands and the other overwrites it, so a whole run's worth of resource records vanishes from state while the resources remain real and billed. The still-running original may also fail its final state write outright and leave `errored.tfstate` behind. Recovery means restoring a state version from the backend's history if nothing has been applied since, or importing the orphans back individually — hours of work to save the ten minutes it would have taken to check whether the job was still running. ## Preventing the recurrence Stuck locks are a symptom. Make CI cancellation graceful where you can, so Terraform gets a chance to release the lock instead of being killed outright; serialise runs per state so a queued job waits instead of failing; and make the lock error surface the `Lock Info` in the job log rather than being swallowed, so the next person starts the investigation with the evidence already in hand.