MailboxProcessor retry policy with idempotency key for external writes

Direct answer

MailboxProcessor has no built-in retry, persistence, replay queue or idempotency support. The agent is single-threaded and in-memory, so any retry state lives only while the process is up.

Idempotency key placement

Generate the idempotency key by the caller before posting and embed it in the message. Confirmed: MailboxProcessor constructors and Post/PostAndAsync/Scan do not accept an idempotency parameter. Likely: caller-side generation keeps token lifecycle outside the agent, survives agent restarts, and allows the caller to decide uniqueness scope. Agent-side generation is possible but ties the key to in-memory agent lifetime and makes re-post after a crash ambiguous.

Retry without stalling the mailbox

Do not perform synchronous external store calls in the receive loop. Confirmed: the receive loop runs on one thread, so a blocking call stalls all messages. Likely safe pattern:

1. Receive message with key and payload.
2. Run the external write in an async workflow via PostAndAsync or Async.StartChild, returning immediately.
3. On transient failure, schedule a retry by posting a new message back to the same agent or to a dedicated retry mailbox with back-off. Use a timer or delayed post, not Thread.Sleep in the loop.
4. Deduplication check is done by the external store using the same key on each attempt; the write operation itself must be idempotent with respect to that key.

Restart behavior

Confirmed: MailboxProcessor state and its mailbox are purely in-memory. On process restart all pending messages, scheduled retries and in-memory token state are lost. Deduplication tokens that were only stored in the agent are lost. Only tokens and retry intent persisted by the caller or in the external store survive. After restart the agent starts empty; you must re-hydrate work from an external durable queue if at-least-once delivery is required.

Confirmed facts vs likely

Confirmed: No built-in retry/persistence/idempotency in FSharp.Core MailboxProcessor API. Single in-process serialization. Mailbox discarded on restart.

Likely, for review: Caller-side key generation and async non-blocking retry via delayed re-post is the practical pattern. Verification needed for your external store consistency model to ensure a retry with the same key is safely ignored.

Missing diagnostic detail that changes recommendation: can the caller durably persist the message + key before posting, and is the external write operation already idempotent by key? If not, agent-side key generation and an external durable outbox are required.