6.2. State Locking

💡 First Principle: State locking exists to enforce one writer at a time — because two simultaneous applies could interleave writes and corrupt the single source of truth — and it's a property the backend provides, not something you code.

Why care: Locking is a frequent exam topic, especially the facts that it's automatic on supporting backends, that not all backends support it, and how to recover from a stuck lock. It's also a real-world source of "Error acquiring the state lock" confusion.

The mental model: Locking is the "occupied" sign on a single-occupancy restroom. While someone's inside (an apply is running), the door locks; others wait. Remove the sign mechanism (an unsupported backend) and two people can collide.

⚠️ Common Misconception: "I have to write code to enable locking." Locking is handled by the backend automatically during state-changing operations — you don't implement it. Your only related actions are choosing a backend that supports it and, rarely, force-unlocking a stuck lock.