The pass is never handed to `spawn_blocking`, so it holds a runtime worker
Defect 6 / Tier 2 / issue
services/proxy/src/sweep.rs:14-18services/proxy/src/routes/admin.rs:76services/proxy/src/main.rs:116Expected review
wrap the pass in `spawn_blocking`, which keeps the cheap synchronous calls and takes them off the async workers.
Discovery difficulty
the module documentation makes a real argument against `tokio::fs`, and it is correct as far as it goes - dispatching each call to the blocking pool individually would be worse. It presents two options and picks the better of them, and the right answer is a third the comment never raises.
Trigger
a sweep over a populated store while requests are in flight. A walk of `blobs/sha256` plus every index entry is tens of thousands of `readdir` and `stat` calls, and one tokio worker is blocked for all of it, so every request scheduled onto that worker stalls. On the on-demand route the caller's own request is the one holding the thread.
Severity
issue