Mutex::lock returns Err(PoisonError) after a panic in std::sync — recover or propagate?

The Decision Criterion

The choice between recovering from a PoisonError or propagating it depends entirely on whether your data's logical invariants can be restored or verified. Because the Rust compiler cannot track the internal consistency of your data structures, the Mutex uses poisoning as a signal that a thread died mid-update, potentially leaving the data in a "half-baked" state.

When to Propagate (Panic)

Propagate the error (typically via .lock().unwrap()) if the guarded data is a critical system state where an inconsistency would lead to silent data corruption or undefined application behavior. If you cannot programmatically verify that the state is valid, panicking is the safest choice to prevent the corruption from spreading to other parts of the system.

When to Recover

Recovery via into_inner() is sound if you can satisfy one of these conditions:

• Reconstructibility: The data is a cache or a set of counters that can be wiped and rebuilt from a source of truth.
• Validation: You can implement a validation function that checks the invariants of the guarded data and resets it if it is found to be inconsistent.
• Triviality: The data is a simple type (like a usize) where any value is technically "valid," even if it is slightly inaccurate.

Implementation Paths

Depending on your goal, use one of the following patterns:

1. Propagation (The "Fail-Fast" Approach)

let guard = mutex.lock().expect("Mutex poisoned: critical state corrupted");

2. Recovery (The "Repair" Approach)

If you need to handle the poison explicitly to perform a reset:

let mut guard = match mutex.lock() {
    Ok(g) => g,
    Err(poisoned) => {
        let mut g = poisoned.into_inner();
        // Perform recovery: e.g., reset counters or clear cache
        g.reset_to_defaults();
        g
    }
};

Comparison: into_inner() vs clear_poison()

Method	Behavior	Semantic Effect
into_inner()	Extracts the guard from the PoisonError.	The Mutex remains poisoned. Subsequent calls to lock() will still return Err.
clear_poison()	Removes the poisoned state from the Mutex.	The Mutex is reset to healthy. Subsequent calls to lock() will return Ok.

Note: Use clear_poison() only after you have successfully validated or repaired the internal state, as it signals to all other threads that the data is once again trustworthy.

Diagnostic Requirement

To refine this recommendation: are the counters in your state used for critical synchronization/logic, or are they purely for telemetry/observability?