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§
- Message
Key - The chat and temporary message ID identifying a tracked send failure.