MailPostProcessingMode

Namespace: Meshmakers.Octo.MeshAdapter.Nodes.Trigger

What a mail trigger does with a message once the pipeline run for it is over (AB#5345). Shared vocabulary of the IMAP (FromEmail@1) and Microsoft Graph (FromMicrosoftGraphEmail@1) channels, so the same three choices mean the same thing on both and a settings page can offer one list instead of two sets of switches.

🔴 The post-processing is applied ONLY on success, and success is a BUSINESS outcome — an inbox item was created — reported by the pipeline through its successPath, never "the execution did not throw". A run can end perfectly normally while a node reported an error and stopped its branch, and no per-node status reaches a trigger. A message whose import is not confirmed is left exactly as the server has it, which is the only durable record that it was never imported.

🔴 There are exactly three modes, and every one of them takes the message OUT of the search the next poll runs — moved out of the source folder, deleted, or flagged \Seen (which the IMAP channel's NotSeen search then skips). That is not a coincidence, it is the whole mechanism: nothing in OctoMesh records which mail was already processed — the mailbox IS the bookkeeping. A fourth member meaning "leave it where it is" existed until AB#5372 (None = 0) and was a defect: combined with the per-poll cap (maxMessagesPerPoll) it re-fetches the same first N messages on every poll and NEVER reaches the mail behind the cap, so the import runs for ever, reports success and imports nothing new — exactly the shape of AB#5336 (1697 mails, three pod restarts, no progress). AB#5345 specified three modes; the fourth was an artefact of implementing them.

Every member is an explicit operator choice. A pipeline that names none has its mode DERIVED from its own legacy properties — see the nodes' ResolveEffectivePostProcessingMode, which now FAILS the trigger start where it used to fall through to None.

⚠️ The members keep the numbers they had. Persistence is by NAME on both routes (ConfigurationSettingsReader.ReadEnum refuses a purely numeric value outright, and YamlDotNet reads the name), so renumbering would buy nothing and risk everything.

public enum MailPostProcessingMode

Inheritance Object → ValueType → Enum → MailPostProcessingMode
Implements IComparable, ISpanFormattable, IFormattable, IConvertible

Fields

Name	Value	Description
MoveToFolders	1	Mode A — source / done / failed folders. A message whose import was confirmed is moved to the done folder, one whose import was not is moved to the failed folder (when configured; otherwise it stays in the source folder). This is the mode that gives an operator a way BACK: moving a message out of the failed folder into the source folder offers it again.
Delete	2	Mode B — source folder only, the message is DELETED once its import was confirmed. The mailbox is the queue and nothing is kept; an unconfirmed message stays.
MarkAsRead	3	Mode C — source folder only, the message is marked as READ once its import was confirmed. Combined with the IMAP channel's onlyUnread search this is the lightest queue: an unconfirmed message stays unread and is offered again.