mirror of
https://github.com/TheFunny/TelegramTwitterMediaBot.git
synced 2026-09-23 23:32:05 +00:00
YoursFunny
5ff921222a
`MEDIA_CLIENT` deliberately has no reqwest total timeout (a 30s cap made a hundreds-of-MB ugoira zip impossible to deliver), and the idle window only covers *silence*: a server that drips a chunk every 29 s keeps the download alive indefinitely. On the bot's side each such download holds one of the process-wide upload-prep slots (`send::upload`'s `PREP_SLOTS`, 6), so a handful of trickling sources can take the whole fallback path out of service without ever looking broken. `DOWNLOAD_TOTAL_TIMEOUT` (600s) bounds the whole transfer, checked between chunks — a transfer that completes just over the budget is kept rather than thrown away, and a genuinely slow link (the case the cap was removed for) stays far inside it. Reported as `Transient` like the idle-window stall: the transfer may simply have been unlucky, and a retry restarts it. Verified with a local trickling server (a 1 KiB chunk every 1.2s, chunked so the client cannot see the total up front): with the budget temporarily lowered to 2s the download aborted after 2425ms with `transient: download exceeded 2s` — two chunks in, the server seeing the client go away — proving the budget and not the 30s idle window ended it. `cargo fmt --check`, `cargo clippy --workspace --all-targets --locked -- -D warnings` and `cargo test --workspace --locked` clean.