Constructor ReconciledFolderOutcome

Namespace

MailFathom.Application.Synchronization.Reconciliation

Assembly

MailFathom.Application.dll

ReconciledFolderOutcome(IReadOnlyList<ObservedEmailFlags>, IReadOnlyList<StoredEmailId>, IReadOnlyList<StoredEmailId>, IReadOnlyList<MutationAttributedDisappearance>, RemotelyDeletedEmailDisposition, DateTimeOffset)

Everything one reconciliation window learned, as one thing to apply.

public ReconciledFolderOutcome(IReadOnlyList<ObservedEmailFlags> StillPresent, IReadOnlyList<StoredEmailId> ConfirmedUnchanged, IReadOnlyList<StoredEmailId> Disappeared, IReadOnlyList<MutationAttributedDisappearance> RemovedByOwnMutation, RemotelyDeletedEmailDisposition Disposition, DateTimeOffset ObservedAt)

Parameters

StillPresent IReadOnlyList<ObservedEmailFlags>

The emails the folder still holds, with the flags to write onto them.

ConfirmedUnchanged IReadOnlyList<StoredEmailId>

The emails the folder still holds and reported no change to, so the stored flags already describe them and only the record of when they were last asked about moves.

Disappeared IReadOnlyList<StoredEmailId>

The emails the folder no longer holds and nothing MailFathom did accounts for.

RemovedByOwnMutation IReadOnlyList<MutationAttributedDisappearance>

The emails the folder no longer holds because MailFathom itself relocated or deleted them, each named with the record that says so. They are separated from Disappeared before the disposition is reached, because the disposition answers what becomes of mail somebody else deleted and these are not that. Applying one is applying an observation and nothing else: the queue timestamp moves so the window can reach further into the folder, and the row itself is left for the relocation to carry across or for the delete action to decide about.

Disposition RemotelyDeletedEmailDisposition

What becomes of the local copy of each disappeared email.

ObservedAt DateTimeOffset

When this window was read, which orders it against what other writers have recorded.

Remarks

The window travels as one value rather than as a call per email so that applying it is one bounded set of database work instead of a query per row inside an open write transaction. It is also what makes the window atomic: a run either records what it found or records none of it.

ObservedAt is the ordering key an implementation compares against what is already stored, so a window replayed after a commit conflict cannot overwrite an observation that is newer than itself. Every snapshot in StillPresent carries its own reading of the same moment, taken where the server answered.

ConfirmedUnchanged is applied like the rest and is not an optimization an implementation may skip. The observation timestamp is what moves an email to the back of the reconciliation queue, so an email the server confirmed and this window left untouched would be selected again on every run and the window would never reach anything else.