-
Notifications
You must be signed in to change notification settings - Fork 34
Open
Labels
debtCode quality issuesCode quality issues
Description
Summary
The codebase has 50+ occurrences of .lock().unwrap() which will panic if a thread holding the lock panics (causing mutex poisoning). While this may be acceptable for internal tools, better error handling would improve robustness.
Current Pattern
let mut environments = self.environments.lock().unwrap();Proposed Improvements
Option 1: Use .expect() with meaningful message
let mut environments = self.environments
.lock()
.expect("environments mutex poisoned - previous thread panicked");Option 2: Handle PoisonError gracefully
let mut environments = self.environments
.lock()
.unwrap_or_else(|poisoned| {
log::warn!("Recovering from poisoned mutex");
poisoned.into_inner()
});Option 3: Use parking_lot::Mutex which doesn't poison
// parking_lot::Mutex doesn't have PoisonError
use parking_lot::Mutex;
let mut environments = self.environments.lock();Files with Most Occurrences
crates/pet-conda/src/lib.rs- ~15 occurrencescrates/pet-python-utils/src/cache.rs- ~10 occurrencescrates/pet-poetry/src/lib.rs- ~8 occurrencescrates/pet-linux-global-python/src/lib.rs- ~5 occurrencescrates/pet-reporter/src/cache.rs- ~5 occurrences
Recommendation
For a JSONRPC server that should be reliable:
- At minimum, replace
unwrap()withexpect("meaningful message")for better debugging - Consider
parking_lotcrate which has better performance and no poisoning semantics - For critical paths (like the reporter), consider graceful recovery
Priority
Low - Current code works but could be more robust.
Copilot
Metadata
Metadata
Assignees
Labels
debtCode quality issuesCode quality issues