Sagas seems to schedule messages before persisting state even when Outbox is enabled.

Is this a bug report?

Yes, I have a reproduction repo here https://github.com/wastaz/MassTransitSagaReproduction

Can you also reproduce the problem with the lastest version?

I can reproduce this with latest stable 3.5.7, not sure about 4.x since we are not using that yet.

Environment

1. Operating system: Windows 10
2. Visual Studio version: Project Rider 2017.1.1
3. Dotnet version: 4.6.2

Steps to Reproduce

Clone repo https://github.com/wastaz/MassTransitSagaReproduction Follow instructions in repos readme.

Expected Behavior

I have a saga with an initial state, and an additional state (with outboxing enabled). Initially it schedules a message, and then it transitions to the waiting for message state. In this state, it should receive the scheduled message and print the content to the console. I have a fake scheduler setup which just immediately delivers the scheduled message to the destination.

I expect that if masstransit sends the ScheduleMessage message after persisting the state then I should never be able to end up with a saga recieving the scheduled message in the wrong state.

Actual Behavior

Occasionally I will receive the following error

R-FAULT rabbitmq://localhost/mtsagarepro_saga N/A Common.ScheduledTransitionMessage MassTransitSagaReproduction.TestState(00:00:00.0506110) The ScheduledStateChange.AnyReceived event is not handled during the Initial state for the TestProcessManager state machine
MOVE rabbitmq://localhost/mtsagarepro_saga N/A rabbitmq://localhost/mtsagarepro_saga_error?bind=true&queue=mtsagarepro_saga_error Fault: The ScheduledStateChange.AnyReceived event is not handled during the Initial state for the TestProcessManager state machine

So in this case the state machine actually recieves the scheduled message while in the initial state. Which shouldnt be possible if I understand how outboxing works correctly.

I have tested this both with the Marten and the MongoDB persistance and observed the same behaviour in both, which makes me suspect that this is persistance-agnostic (given that the persistance is slow enough that the FakeScheduler has a chance of beating it 😉 ).

Reproducible Demo

https://github.com/wastaz/MassTransitSagaReproduction See Readme for instructions on running.

[phatboyg]

Order matters, it’s a pipeline: https://github.com/wastaz/MassTransitSagaReproduction/blob/master/MassTransitSagaReproduction/MassTransitModule.cs#L52

Put the OutBox before the saga is registered.

[wastaz]

@phatboyg Ok…well…Im not really sure if I understand you correctly? I am using the outbox feature, so from the docs I would expect the flow to be

1. Recieve message from rabbitmq and route to saga
2. Run the state machine steps which in this case would record a state transition in the state and put the ScheduleMessage message in the outbox
3. Persist state to disk
4. Send all messages in outbox on bus
5. Ack message from RabbitMQ

…and if this is how it works, then I dont see how locking or non-locking would affect this in any way since the state should be persisted to disk before the messages in the outbox are sent at all, given that outbox is enabled?

If this is not how the outbox feature works then please correct me. 😃