title: How does Mass Transit handle retries deduplication and message id generation when using in-memory outbox
body: <p>Mass Transit has an in-memory "outbox" implementation that I think will handle the majority of the concerns / challenges I am looking to over come however I can not find a lot of documentation that describes its capabilities in the detail I am looking for. A lot of these questions came about after watching a video where Udi Dahan explains how to handle reliable messaging without distributed transactions (<a href="https://vimeo.com/111998645" rel="nofollow noreferrer">https://vimeo.com/111998645</a>).</p>
  
  <ol>
  <li>Does the in-memory outbox handle failures that may happen when trying to send a message to the queue? So for example: A consumer generates 3 messages that are collected in the outbox. The consumer completes without issue.The collected messages in the outbox start being processed
  
  <ul>
  <li>If from some reason while processing the collected message there is a network issue (or other issue) and message 2 fails to be sent what will happen to message 2 and 3? Is there any sort of retry policy?</li>
  <li>What happens if a message being processed in the outbox is successfully added to the queue but is unsuccessfully marked as sent in the outbox? Will there be another attempt to send the message to the queue?</li>
  <li>Assuming the outbox will retry sending a message to a queue if there is some sort of failure is the message ID guaranteed to be consistent between attempts? Having a consistent Message ID is important for de-duplication to ensure we do not process the same message multiple times.</li>
  </ul></li>
  <li>When a message is consumed is there any de-duplication that takes place? (This ties back to 1.C)
  
  <ul>
  <li>How does Mass Transit track processed records for each consumer? Do the storage engines take care of this responsibility?</li>
  </ul></li>
  <li>Is there any sort of "transaction" exposed to the consumer that allows you to clear the collected message in the outbox without throwing an exception or is throwing an exception the only way to rollback the outbox?
  
  <ul>
  <li>What about messages that are generated outside of a consumer, Is there a way to rollback messages collected in the outbox (example: A WebAPI controller action)?</li>
  </ul></li>
  <li>Is there a recommendation to use the DTC features of Mass Transit instead of outbox or vice versa or use them both?</li>
  <li>Currently Mass Transit does not have an outbox implementation that can survive a process crash. Is there a plan to include such a feature? Is there a road map this is tracked on?</li>
  </ol>