Method ReadPlacementsAtAsync

Namespace

MailFathom.Application.Mail.Mutations

Assembly

MailFathom.Application.dll

ReadPlacementsAtAsync(MailAccountId, RemoteFolderPath, ImapUidValidity, IReadOnlyCollection<ImapUid>, CancellationToken)

Reads the mutations that named one folder as their destination and placed an email at one of these UIDs.

Task<IReadOnlyList<MailboxMutationRecord>> ReadPlacementsAtAsync(MailAccountId accountId, RemoteFolderPath destinationPath, ImapUidValidity uidValidity, IReadOnlyCollection<ImapUid> uids, CancellationToken cancellationToken)

Parameters

accountId MailAccountId

The account whose mutations are read.

destinationPath RemoteFolderPath

The remote folder being synchronized, which is the destination those mutations named.

uidValidity ImapUidValidity

The UIDVALIDITY that folder reports now.

uids IReadOnlyCollection<ImapUid>

The UIDs one batch of the forward pass discovered.

cancellationToken CancellationToken

Cancels the read.

Returns

Task<IReadOnlyList<MailboxMutationRecord>>

Every record whose reported placement is one of those occurrences, which may be none.

Remarks

A whole batch of discoveries is asked about at once, so a folder that has no placement pending — which is nearly every folder on nearly every run — costs one query rather than one per message. The batch's own UIDs bound the answer, so no limit has to be invented for it and no candidate can be missed by one. Which record a given occurrence belongs to is then decided by AccountsForPlacementAt(RemoteFolderPath, ImapUidValidity, ImapUid), which restates every condition of the read rather than trusting it.

A relocation and a copy are both read, because both put a message where the forward pass will meet it and the discovery is MailFathom's own act either way. What the two then do differs — a relocation carries the local email onto the new occurrence and a copy does not — and that is the caller's decision rather than this read's.

Exceptions

ArgumentNullException

Thrown when uids is null.