Downloads intermittently stall mid-transfer (not fail, just stop, indefinitely, no error) and never recover without restarting the server container. Reproduced repeatedly on a large multi-chunk game (~965MB) at different byte offsets, both times far from finished (259.7/964.9 MB and 638.7/964.9 MB).
Symptoms
- Download progress just freezes. No client-side error.
- torrential logs go completely silent after a single
continuing download for {id} line, no further activity for that request.
ss -tnp on the host shows the relevant TCP socket(s) sitting ESTAB with empty send/recv queues, idle, not backpressured.- Web UI and unrelated requests keep working fine the whole time (rules out full container death/crash).
docker restart on the Drop container clears it instantly.- Once, instead of a permanent hang, got a bare 502 without a restart, consistent with an upstream reverse-proxy read-timeout eventually killing the stuck connection.
What I ruled out
Suspected: NFS/FUSE storage-layer hang first (library is served off a FUSE-mounted network share).
Disproven: direct dd reads of the exact files being served, run live during an active stall, completed instantly every time. Not a storage issue, points at something in torrential's request-handling itself.
Fix attempt
Based on where the stall seemed to be happening in torrential/src/downloads/serve.rs, I tried a fix around how the per-download context cache is locked during chunk serving, restructuring things so the lock is released earlier instead of being held across the slower parts of handling a request. Built a patched image, deployed it to my real instance, and repeated the exact usage pattern that reliably stalled every download before (multiple games, same access pattern). Ran 4-5 full downloads afterward with no stalls at all.
Happy to open a PR with the fix if needed.
Environment
- Drop
0.4.0-rc-5, self-hosted, Docker Compose (postgres:14-alpine + ghcr.io/drop-oss/drop:0.4.0-rc-5), managed via Arcane.io
- Library on a FUSE-mounted network share (ruled out as cause, see above)
- Reverse proxy chain: internal nginx (bundled) → Caddy
Downloads intermittently stall mid-transfer (not fail, just stop, indefinitely, no error) and never recover without restarting the server container. Reproduced repeatedly on a large multi-chunk game (~965MB) at different byte offsets, both times far from finished (259.7/964.9 MB and 638.7/964.9 MB).
Symptoms
continuing download for {id}line, no further activity for that request.ss -tnpon the host shows the relevant TCP socket(s) sitting ESTAB with empty send/recv queues, idle, not backpressured.docker restarton the Drop container clears it instantly.What I ruled out
Suspected: NFS/FUSE storage-layer hang first (library is served off a FUSE-mounted network share).
Disproven: direct
ddreads of the exact files being served, run live during an active stall, completed instantly every time. Not a storage issue, points at something in torrential's request-handling itself.Fix attempt
Based on where the stall seemed to be happening in
torrential/src/downloads/serve.rs, I tried a fix around how the per-download context cache is locked during chunk serving, restructuring things so the lock is released earlier instead of being held across the slower parts of handling a request. Built a patched image, deployed it to my real instance, and repeated the exact usage pattern that reliably stalled every download before (multiple games, same access pattern). Ran 4-5 full downloads afterward with no stalls at all.Happy to open a PR with the fix if needed.
Environment
0.4.0-rc-5, self-hosted, Docker Compose (postgres:14-alpine+ghcr.io/drop-oss/drop:0.4.0-rc-5), managed via Arcane.io