Skip to main content

Module message

Module message 

Source
Expand description

Terminal message-send results and temporary message identities.

A direct TDLib send response can contain a local temporary message. Successful submission is not necessarily successful delivery. Client::track and Client::track_all bind pending identities before the request wakes, then wait for send-success, send-failure, or non-cache deletion updates. Every original update remains available through Session::recv.

§Supported requests

Use tracked methods for normal sends, such as sendMessage, sendMessageAlbum, and normal non-preview forwardMessages calls. Generic return-type bounds are not a promise to track every function returning Message or Messages. Previews, getters, and edits belong on Client::send; an unsupported pending-looking response may never finish. Already-final direct responses return without waiting for a terminal update.

Edits use their direct correlated response. An updateMessageEdited event cannot establish which edit request finished or whether another edit failed.

§Cancellation

A borrowed CancellationToken asks the operation to delete pending temporary messages. It does not retract the initial request: even a pre-cancelled token waits for the direct response so the temporary identity can be bound.

An authoritative success already observed wins and returns the final message. Deletion is requested only for a temporary ID still registered as pending; this library never explicitly deletes a successful final ID. This is not server-atomic: TDLib can itself delete a concurrently accepted message after removing its pending record. Do not interpret cancellation as a guarantee that the message was never visible or that a racing successful message remains.

Dropping the future merely abandons local observation. Submitted native work continues; token-triggered cleanup only runs while the future is driven. Reusing a cancelled token asks every subsequent operation using it to cancel.

If an application stop signal wins a race, cancel the token and keep awaiting the same send future so native cleanup can finish:

let cancel = CancellationToken::new();
let sending = client.track(request, Some(&cancel), None);
tokio::pin!(sending);
tokio::select! {
  result = &mut sending => result,
  () = stop => {
    cancel.cancel();
    sending.await
  }
}

§Upload measurements

Pass an optional borrowed callback to observe primary media files. Supported payloads are animations, audio, documents, photos (the last returned size), stickers, videos, video notes, and voice notes. Thumbnails and recursive attachment traversal are not tracked. There is no preliminary-upload API.

Samples can coalesce across album items; neither a callback for every item nor a final 100% sample is guaranteed. See Progress and the transfer guide for the common measurement contract.

Structs§

MessageKey
The chat and temporary message ID identifying a tracked send failure.