Designing Resilient State Machines

In this lesson, you will learn how to use Result transitions to transform your state machine into a self-validating system that makes illegal states unrepresentable.

The Problem with Mutability

In simple state machines, we often use methods that consume self and return a new state. However, if a transition requires an external resource—like a database connection or a hardware sensor—the operation might fail. If your transition function doesn't account for this, you risk leaving the machine in an undefined state or crashing the program.

Encoding Resilience in Transitions

Instead of having methods that return Self, we design our state machine methods to return Result<NewState, TransitionError>. This pattern forces the caller to acknowledge that a transition is a fallible operation. By returning a Result, we ensure that if a transition fails, the original state remains intact and accessible, allowing for graceful recovery or retries.

Consider a Door state machine:

struct Locked;
struct Unlocked;

impl Locked {
    // If the key is invalid, the transition fails, 
    // but we still hold our 'Locked' state.
    fn unlock(self, key: &str) -> Result<Unlocked, &'static str> {
        if key == "secret_password" {
            Ok(Unlocked)
        } else {
            Err("Invalid key: access denied")
        }
    }
}

Why this works

By requiring the consumption of the current state, we guarantee that the state machine cannot exist in two places at once. By wrapping the return value in a Result, we create a "transactional" boundary. If the operation succeeds, the old state is consumed and the new state is produced. If it fails, the error is propagated, and the original state is technically still available (or dropped safely), preventing the machine from ever sliding into an invalid configuration.

This approach turns your state transitions into atomic operations. It effectively moves the validation logic into the type system, ensuring that the only way to reach a state is to successfully complete the fallible transition.

Key Takeaway: Use fallible Result transitions to ensure your state machine only advances when an operation is confirmed, keeping the system stable even when external conditions fail.