highAdvancedSymptom-first#lock#concurrent#ci#dangerous

Lock warning — using -lock=false during concurrent runs

Warning: -lock=false is set, skipping state lock

Likely source:configurationdata-loss

Focused incident mode — strips away everything but this runbook.

Symptoms

  • Warning: -lock=false is set, skipping state lock
  • terraform apply with -lock=false runs without acquiring the state lock
  • State corruption from concurrent writes when lock is bypassed

-lock=false is a last resort, never a default. If locks are slow, fix the lock timeout or DynamoDB capacity, not the safety mechanism.

Evidence to grab

Collect these artifacts before you change anything — they prove (or rule out) each cause.

  • Lock warning in output

    terraform apply -lock=false 2>&1 | head -10
  • CI pipeline running concurrent applies

    grep -r 'lock=false' .github/ .gitlab-ci* Jenkinsfile 2>/dev/null

Diagnostic flow

Run the steps in order, marking each claim confirmed or refuted. The evidence you gather feeds the ranked causes below.

Guided decision tree is ready.

Steps with commands, expected output, and pass/fail branches.

Ranked root causes

Evidence checklist

  • Makefile or CI config uses terraform apply -lock=false
  • Concurrent PRs trigger parallel applies

Confirm before fixing

grep -rn 'lock=false' --include='*.yml' --include='*.yaml' --include='Makefile' .
READ

Find the -lock=false usage

Fix

sed -i 's/-lock=false//g' Makefile
CHANGE

Remove -lock=false from the build

Resolution runbook

Apply from top to bottom after the cause is confirmed. Review every command before running it — risk tags are shown on each.

1
grep -rn 'lock=false' --include='*.tf' --include='*.yml' --include='Makefile' .
READ

Find all -lock=false usages

2
sed -i 's/-lock=false//g' <FILE>
CHANGE

Remove -lock=false from the build

3
terraform force-unlock <LOCK_ID>
CHANGE

Clear any stale locks that caused the bypass

4
terraform plan -lock=true
READ

Verify normal locking works

Prevention

  • Never use -lock=false in CI pipelines.
  • Set -lock-timeout=300s to fail fast instead of hanging.
  • Add a CI lint step that fails if -lock=false is detected.
  • Monitor DynamoDB capacity and auto-scale the lock table.

Commands marked READ CHANGE DESTRUCTIVE — never run DESTRUCTIVE commands against production data you cannot restore. Copy → verify → execute.