Does MassTransit In-Memory Outbox work with Mediator?-CodePudding

Does the In Memory Outbox only work with an underlying messaging transport configured. The documentation and some of the various posts I have read are leading to believe me that it will ONLY work with a specific underlying transport specified. It would be nice if that wasn't the case.

I say this as I have read discussion around the outbox and acknowledging messages "from a broker" and only once all processing has completed successfully - messages are acknowledged and publishing occurs.

So, when handling the messaging (i.e. via Amazon SQS) oneself and publishing messages into the state machine (i.e taking the transport message, creating a new message and then handing off to publishing to a consumer or saga state machine, how would the outbox know about and work with underlying transport messages.)

To be really clear, will the outbox work when using the following configuration (note the absence of any messaging transport configuration) :

   services.AddMediator(configurator =>
            {
                configurator.AddConsumer<PublishMessageConsumer>();
                configurator.AddSagaStateMachine<YetAnotherStateMachine, YetSomeMoreState>(
                    sagaConfigurator =>
                    {
                        sagaConfigurator.UseInMemoryOutbox();
                    }).DynamoDbRepository()
      /// Snip
    });

If it DOES work - if I wanted a consumer AND the Saga statemachine to work in concert such that the the Saga published to the Consumer and the Consumer failed for some reason. What would actually happen?

CodePudding user response：

The sole purpose of the in-memory outbox is to defer calls to Send/Publish until after the consumer has completed. In the case of a saga, it means after the saga has been persisted to the saga repository after all state machine behaviors for the event have completed successfully (without throwing an exception).

In the case above, the saga would complete all activities for triggering event, the instance would be saved to the saga repository, and finally the consumer would be created/called by the Send/Publish call from the saga.

If the consumer throws an exception, it won't affect the already persisted saga instance in any way, as that has already completed.

NOW. If you do NOT use the in-memory outbox in this scenario, since it is using mediator (and not a transport), if you call Send/Publish in a state machine activity, control is transferred immediately to the consumer of the message sent/published. After that consumer completes, controls returns to the saga, which once the activities have completed would be persisted to the repository and the original message consumed by the saga completes, returning control to the original Send/Publish call.

Mediator is immediate, and any messages produced by consumers and/or sagas are consumed immediately as well.