mirror of
https://github.com/TheFunny/TelegramTwitterMediaBot.git
synced 2026-09-23 23:32:05 +00:00
YoursFunny
362eb9e729
Each batch's items were prepared under their own `Semaphore::new(3)`, which is not a memory bound: 8 URL workers and 4 queue workers can each be inside a batch, so a burst could have two dozen downloads in flight at once, each buffering a whole photo before it is processed. Nothing else on the media path bounds them — the send itself is paced by the rate limiter, but the download and the decode happen before it is charged. One process-wide `PREP_SLOTS` (6) replaces the per-batch semaphore, and the photo download gets its own cap: `MAX_PHOTO_DOWNLOAD_BYTES` (32 MiB) for the transfer, with `MAX_DECODE_BYTES` (512 MiB) left as the pre-allocation guard on a single decoded buffer. A photo over the download cap degrades to its smaller URL exactly as one over the decode budget does (`FallbackError::MediaTooLarge` → `fallback_url`) — never an error. Verified with the same throwaway proxy harness: 4 concurrent 10-item batches against a server that holds every response 150 ms peak at exactly 6 concurrent downloads (the per-batch three allowed 12) with all 40 items prepared. `cargo fmt --check`, `cargo clippy --workspace --all-targets --locked -- -D warnings` and `cargo test --workspace --locked` clean.