State Lock Breakage and Recovery

Every operation that would write state takes an exclusive lock first, and most that would merely read consistent state take a shared one. The mechanism differs by backend — the local backend writes a .terraform.tfstate.lock.info file beside the state, S3 records a conditional-write item in DynamoDB (the lock table from this phase), Terraform Cloud registers the lock against the workspace's run — but the contract is uniform: only one writer at a time. Two concurrent applies without that guarantee would interleave state writes, and whichever finished last would erase the other's record of created objects, orphaning real infrastructure that nothing tracks. The lock is the database's row lock, applied to your entire estate.

The lock's weakness is its owner's lifecycle. A lock is released by the process that took it — on successful completion, or on a graceful interrupt. When the process dies without that release path — a CI runner reclaimed mid-apply, kill -9, a laptop that sleeps through a VPN drop, an IDE crash — the backend never hears the goodbye, and the lock outlives the operation. Note the granularity: the lock covers the entire state object, not individual resources, so one stuck apply blocks every other change to that stack — a deliberate design choice, because partial state writes are precisely what interleaving would corrupt. Every subsequent command that needs the lock fails, identically, for everyone:

Error: Error acquiring the state lock

Error message: ConditionalCheckFailedException: The conditional request failed
Lock Info:
  ID:        2e9dfc30-4d33-4ba5-b3ae-20e19c37a1c2
  Path:      acme-tfstate-prod/prod/network/terraform.tfstate
  Operation: Apply
  Who:       alice@laptop
  Version:   1.6.2
  Created:   2026-01-10T09:14:22Z

Note what the error is not: it is not corruption, and it is not data loss. A stale lock is a stopped door, not a broken building — Terraform is refusing to proceed precisely because it cannot guarantee the previous writer finished cleanly. The Lock Info block is the backend telling you everything it knows about the holder: the ID you will need to force-unlock, the Operation that took it (Apply, Plan, Unlock), Who (CI service account or a human's workstation), and Created — the age, which is the single most decision-relevant field. A lock created forty seconds ago belongs to a teammate's run in flight; one created four hours ago on a laptop that has since been closed is the stale kind.

The trap for the uninitiated is treating the error as an obstacle to route around. -lock=false on a plan, hand-editing state, pointing at a different workspace — each of these converts a one-minute recovery into a genuine incident. The correct response is the next chapter's subject: diagnose what holds the lock before deciding whether it should be broken. One prevention note worth internalizing before the incident happens at all: locks and plans interact the same way they do for applies, so two engineers running plan concurrently on a remote backend can contend too — usually resolved by one waiting, occasionally by the same stale-lock error if one of the two plans dies. The habit of checking the CI dashboard before assuming malice extends to plans as well.

Before any unlock, one question must have an evidence-based answer: is an operation genuinely in progress? Breaking the lock of a live apply is the one move in this entire phase that can corrupt state, so the diagnosis is not bureaucracy — it is the safety interlock. Work the fields in order:

• Created vs now. An age longer than any plausible plan/apply duration for this stack (four hours for an estate that normally applies in six minutes) means stale. An age of ninety seconds means wait.
• Who. A CI service account points at a runner — check the pipeline's run history for an in-flight or killed job. A human's workstation means a message in the team channel: "your apply from 09:14 still holds the state lock — did it finish?" Thirty seconds of asking beats an hour of archaeology.
• Operation. Locks taken by Unlock or Plan are lower-stakes than Apply — an interrupted plan changes nothing, an interrupted apply may have left state mid-write.

Backends with real locking make this cheap precisely because they record the holder: S3+DynamoDB stores the Lock Info as the item's attributes, readable directly from the table; Terraform Cloud/Enterprise surfaces the holding run in the workspace UI, with a cancel button that releases the lock as a side effect. Teams on such backends recover in minutes; teams that configured state without locking never face stale locks but pay for it in race conditions instead — a trade already covered in Limitations of Local State Files. The habit worth building is to treat the lock error as a notification rather than a wall: paste the Lock Info block into the team channel, and let the person named in the Who field confirm or deny in their own words — the fastest recovery is almost always the one where the holder unlocks it themselves, because they can also tell you whether the state write completed.

While diagnosing, gather read-only evidence that does not need the lock:

terraform state list                       # state commands take no write lock
terraform show 'aws_instance.web'          # attributes intact?
terraform plan -lock=false                 # what does the estate look like now?

That last command deserves care: -lock=false on a plan is the sanctioned read escape hatch (it may read slightly stale state, which is acceptable for diagnosis), but never pass -lock=false to an operation that writes state or to apply — you would be doing the exact thing the lock exists to prevent, deliberately.

The verdict shapes the next step. Genuinely running → wait, or cancel the run properly in the CI system so it unlocks itself. Confirmed dead → terraform force-unlock with the recorded ID. Unknown → keep asking; "I could not determine the holder" is never a state in which to break a lock, because the cost asymmetry is brutal: waiting costs minutes, corrupting state costs an incident review. When the holder genuinely cannot be identified — an expired CI service account, a departed contractor's laptop — the safe ordering is to confirm with whoever owns the pipeline today, then unlock: the conversation takes five minutes and is the only verification available.

The command is short and deliberately gated:

terraform force-unlock 2e9dfc30-4d33-4ba5-b3ae-20e19c37a1c2

Terraform will remove the lock for the state ID shown below.
Do you really want to force-unlock?
  Type 'yes' to confirm:
> yes

Successfully unlocked state 2e9dfc30-4d33-4ba5-b3ae-20e19c37a1c2

Three properties to internalize. First, it requires the lock ID shown when the lock was created — not the path, not the workspace name. There is no wildcard, no "unlock whatever is there": you must name the exact lock, which means you must have read the Lock Info block, which means you diagnosed first. That friction is by design. Second, the typed yes confirmation exists because the command cannot verify what you could not: Terraform does not know whether the holder is alive. Third, force-unlock changes only the lock record — it does not repair whatever the interrupted operation left behind, and after unlocking, state is exactly as the dead process left it. If you pass an ID that does not match the current lock, the command fails rather than unlocking whatever is held; there is no "close enough".

Which is why the risk statement deserves precision. If the interrupted apply wrote state partway — created three of five resources, then died — the lock was protecting that inconsistent window. Breaking it is correct because the writer is gone; running a new apply immediately after is not, until you have verified what the dead run left. Inspect with the lock-free read commands, then plan: resources created-but-unrecorded appear as to be created (and applying blindly risks a name-conflict failure — or worse, a duplicate where the API allows one), while resources recorded-but-half-configured appear as in-place updates. The plan after a forced unlock is your reconciliation report; read it before answering with apply. And if the reconciliation shows something unexpected — a database instance half-created, a security group with rules the dead apply never recorded — prefer repair-by-hand over speed: the lock was broken, not the state, and a careful hour here is cheaper than recreating production from a snapshot later.

Two backend notes round out the operation. With the local backend, the lock is a plain .terraform.tfstate.lock.info file — recovery is deleting that file, and the same rule applies: only when no run is live. With S3+DynamoDB, force-unlock performs a conditional delete of the LockID item, which is why the ID argument is mandatory. And prevention is cheaper than recovery every time: pass -lock-timeout=1m in CI so short lock contention waits instead of failing the job (contention is not staleness), set CI job timeouts shorter than your team's patience so killed runners are visible, and never Ctrl-C an apply you can let finish — a completed apply releases its own lock. The state-operations phase closes here: you can inspect state, relocate entries, adopt objects, declare refactors in code, and recover the lock that stops everything — the foundation on which Module Block Anatomy builds next. Rehearse the unlock once in a development stack; the first time you run it should not be during an incident.