Struct MediaReupload 

pub struct MediaReupload<'a> { /* private fields */ }

Implementations

impl<'a> MediaReupload<'a>

pub async fn request( &self, req: &MediaReuploadRequest<'_>, ) -> Result<MediaRetryResult, MediaReuploadError>

Request the server to re-upload media for a message with an expired URL.

Returns the new directPath on success, or an error variant indicating why the reupload failed.

Protocol flow

1. Encrypt ServerErrorReceipt protobuf with HKDF-derived key from media key
2. Send <receipt type="server-error"> with encrypted payload + <rmr> metadata
3. Wait for <notification type="mediaretry"> response
4. Decrypt response and extract new directPath

pub async fn request_many( &self, reqs: &[MediaReuploadRequest<'_>], ) -> Vec<Result<MediaRetryResult, MediaReuploadError>>

Request reupload for several messages at once, concurrently.

Each request registers its own notification waiter and awaits it independently, so a bulk recovery — e.g. many expired-URL media after a long offline period — runs MEDIA_REUPLOAD_CONCURRENCY at a time instead of paying the serial sum of per-item waits. A batch larger than that runs in waves, so the worst case is ceil(len / MEDIA_REUPLOAD_CONCURRENCY) MEDIA_RETRY_TIMEOUT windows. Results are returned in the same order as reqs; each entry carries that item’s success or error (one item failing never aborts the others).

Duplicate msg_ids in one batch are rejected (past the first occurrence) with MediaReuploadError::InvalidRequest. The mediaretry waiter filters on message id alone and resolve_waiters wakes every match, so two same-id waiters would cross-resolve. Serializing them isn’t enough: once the first waiter times out it lingers in node_waiters (canceled waiters are purged only lazily), so its late notification could still resolve a same-id retry with the wrong payload. Requiring unique ids means no two waiters ever share a filter — a message id is unique per message, so a duplicate is a caller mistake, not a real recovery target.