You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Replace .lock().unwrap() with .expect() for better mutex poisoning diagnostics (#303)
The codebase had 39 occurrences of `.lock().unwrap()` in source files.
These provide no context when mutex poisoning occurs, making debugging
difficult.
## Changes
- Replace all `.lock().unwrap()` with `.expect("<mutex_name> mutex
poisoned")` in 12 source files
- Update documentation example in `pet-core/src/lib.rs` to follow the
new pattern
- Test files intentionally unchanged (panicking on test setup is
acceptable)
### Before
```rust
let mut environments = self.environments.lock().unwrap();
```
### After
```rust
let mut environments = self.environments.lock().expect("environments mutex poisoned");
```
## Files Modified
- `pet-python-utils/src/cache.rs`, `env.rs`
- `pet-reporter/src/collect.rs`, `stdio.rs`
- `pet-core/src/os_environment.rs`, `lib.rs`
- `pet-pyenv/src/lib.rs`
- `pet-uv/src/lib.rs`
- `pet-windows-registry/src/lib.rs`
- `pet/src/jsonrpc.rs`, `find.rs`, `lib.rs`
<!-- START COPILOT ORIGINAL PROMPT -->
<details>
<summary>Original prompt</summary>
>
> ----
>
> *This section details on the original issue you should resolve*
>
> <issue_title>Refactor: Replace .lock().unwrap() with proper error
handling or expect()</issue_title>
> <issue_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
> ```rust
> let mut environments = self.environments.lock().unwrap();
> ```
>
> ## Proposed Improvements
>
> ### Option 1: Use `.expect()` with meaningful message
> ```rust
> let mut environments = self.environments
> .lock()
> .expect("environments mutex poisoned - previous thread panicked");
> ```
>
> ### Option 2: Handle PoisonError gracefully
> ```rust
> 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
> ```rust
> // parking_lot::Mutex doesn't have PoisonError
> use parking_lot::Mutex;
> let mut environments = self.environments.lock();
> ```
>
> ## Files with Most Occurrences
> 1. `crates/pet-conda/src/lib.rs` - ~15 occurrences
> 2. `crates/pet-python-utils/src/cache.rs` - ~10 occurrences
> 3. `crates/pet-poetry/src/lib.rs` - ~8 occurrences
> 4. `crates/pet-linux-global-python/src/lib.rs` - ~5 occurrences
> 5. `crates/pet-reporter/src/cache.rs` - ~5 occurrences
>
> ## Recommendation
> For a JSONRPC server that should be reliable:
> 1. At minimum, replace `unwrap()` with `expect("meaningful message")`
for better debugging
> 2. Consider `parking_lot` crate which has better performance and no
poisoning semantics
> 3. For critical paths (like the reporter), consider graceful recovery
>
> ## Priority
> Low - Current code works but could be more robust.</issue_description>
>
> ## Comments on the Issue (you are @copilot in this section)
>
> <comments>
> </comments>
>
</details>
<!-- START COPILOT CODING AGENT SUFFIX -->
- Fixes#289
<!-- START COPILOT CODING AGENT TIPS -->
---
✨ Let Copilot coding agent [set things up for
you](https://github.com/microsoft/python-environment-tools/issues/new?title=✨+Set+up+Copilot+instructions&body=Configure%20instructions%20for%20this%20repository%20as%20documented%20in%20%5BBest%20practices%20for%20Copilot%20coding%20agent%20in%20your%20repository%5D%28https://gh.io/copilot-coding-agent-tips%29%2E%0A%0A%3COnboard%20this%20repo%3E&assignees=copilot)
— coding agent works faster and does higher quality work when set up for
your repo.
---------
Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
Co-authored-by: karthiknadig <3840081+karthiknadig@users.noreply.github.com>
0 commit comments