Constructor MailboxReconciliationResult
- Assembly
- MailFathom.Application.dll
MailboxReconciliationResult(int, int, int, int, int, int, bool, ulong?, IReadOnlyList<SuppressedMailboxChange>)
Summarizes one bounded reconciliation window.
public MailboxReconciliationResult(int ObservedEmailCount, int RemotelyDeletedEmailCount, int OwnMutationCompletedEmailCount, int SeenStateChangedEmailCount, int FlaggedStateChangedEmailCount, int KeywordsChangedEmailCount, bool EmailsRemain, ulong? ReconciledThroughModSeq, IReadOnlyList<SuppressedMailboxChange> SuppressedChanges)
Parameters
ObservedEmailCountintHow many stored occurrences the server still holds, whether it described them or only confirmed them.
RemotelyDeletedEmailCountintHow many stored occurrences the folder no longer holds and nothing MailFathom did accounts for.
OwnMutationCompletedEmailCountintHow many stored occurrences left the folder because MailFathom relocated or deleted them. They are counted apart from the remotely deleted ones because they are the opposite finding: a change of the owner's own that has come back through synchronization, rather than one to react to.
SeenStateChangedEmailCountintHow many stored emails the server reported a moved
\Seenflag for that no mutation of MailFathom's accounts for. Those are the mailbox owner's own act — read in their client, or marked read there — and they stay a change to react to, which is what keeps the suppression beside them about provenance rather than about the flag.FlaggedStateChangedEmailCountintHow many stored emails the server reported a moved
\Flaggedflag for that no mutation of MailFathom's accounts for, which is the owner starring or unstarring mail in their own client.KeywordsChangedEmailCountintHow many stored emails the server reported different keywords for that no mutation of MailFathom's accounts for, which is the owner labelling mail in their own client. It counts emails rather than keywords, because a set is what a server reports and what a comparison decides.
EmailsRemainboolWhether occurrences still await reconciliation after this window.
ReconciledThroughModSequlong?The folder modification sequence this pass covered the whole folder through, or null when the pass was partial or the server reports no sequence. A caller records it on the folder's checkpoint.
SuppressedChangesIReadOnlyList<SuppressedMailboxChange>The changes this window found and did not raise, because MailFathom itself had made them. The list is bounded by the mutations MailFathom has in flight rather than by the size of the window, so it is a handful on the runs that have any and empty on every run of a mailbox nobody writes to.
Remarks
Every field is a count, a sequence number, or an identity MailFathom owns. Nothing derived from a message belongs in a result a worker logs, which is what makes the audit line this becomes safe to emit for a mailbox nobody may read.