Method WithdrawAppendedAsync
- Namespace
- MailFathom.Application.Mail.Mutations
- Assembly
- MailFathom.Application.dll
WithdrawAppendedAsync(ImapUidValidity, ImapUid, CancellationToken)
Takes a copy this session's folder was given by an earlier append back out of it.
Task WithdrawAppendedAsync(ImapUidValidity uidValidity, ImapUid uid, CancellationToken cancellationToken)Parameters
uidValidityImapUidValidityThe UIDVALIDITY the append reported, which must still be the folder's.
uidImapUidThe UID the append reported for the copy.
cancellationTokenCancellationTokenCancels the withdrawal.
Returns
- Task
A task that completes when the folder no longer holds the copy.
Remarks
It exists so a mirrored copy of an undelivered message does not outlive the wait it was showing. The UID is one the server itself named when it accepted the copy, so this reaches a message MailFathom put there and can reach no other — which is what separates it from the delete a mutation performs on the owner's own mail.
The UIDVALIDITY is compared before anything is issued, because a folder recreated since the append renumbered
every message in it and the recorded UID would name somebody else's. A bare EXPUNGE is never issued, so a
server without UID EXPUNGE is refused rather than served: removing every message anybody flagged
\Deleted is not a side effect this may have.
A copy the folder no longer holds is not an error. The owner deleting it themselves is the ordinary case, and what was asked for — that the copy is gone — is already true.
Exceptions
- MailboxMutationUnsupportedException
Thrown when the server advertises no
UIDPLUS, so no message-scoped expunge exists.- MailboxUnavailableException
Thrown when the mail server did not serve the withdrawal within its configured resilience budget.
- MailboxFolderRecreatedException
Thrown when the folder no longer reports the UIDVALIDITY the append named.