mirror of
https://github.com/TheFunny/TelegramTwitterMediaBot.git
synced 2026-09-23 23:32:05 +00:00
YoursFunny
a1c452f19d
A failed bsky video remux was reported as `FetchError::Transient`, so the fetch loop retried the *whole* adapter — master playlist, variant playlist and up to 500 segments again (256 MiB of cap each time), for a failure that happened near the end of the work the retry was about to redo. The message had to stay honest (returning `Ok` with no media reads as "this post has no media"), so it needed a class of its own. `FetchError::MediaPrep` is that class: post fetched, media could not be prepared locally, not retryable (the per-site `is_retryable` whitelist excludes it by construction), with its own user-facing text — the generic "failed to fetch" would have hidden that the download or encode was what broke. The retry itself is not lost, it moved: `fetch_hls` retries the request that actually failed, once, for the classes a retry can change (transport, 429/5xx). Checked the sibling sites before widening the change: pixiv already degrades to no media when the ugoira encode fails (`Ok(None)`), and its frame-zip download failure is the last step so a re-fetch re-does only that; twitter's auth leg replays two cheap metadata GETs and a GraphQL 5xx *is* worth retrying. Neither needed the new class. Verified with a throwaway proxy harness: a 503 answered twice-in-a-row path costs 2 requests and succeeds, a 404 costs exactly 1 and fails (no pointless retry). `site::bsky::interface::tests::media_prep_failure_is_not_retried` pins the classification. `cargo fmt --check`, `cargo clippy --workspace --all-targets --locked -- -D warnings` and `cargo test --workspace --locked` clean.