[SAGA] Cannot reschedule the message in ".Received" statement

162 views
Skip to first unread message

Carmine

unread,
Sep 13, 2017, 9:35:48 AM9/13/17
to masstransit-discuss

Hi,


I found an issue in Schedule\Unschedule flow within a saga using Azure Service Bus.

Supposing to have a saga and when it’s in Start state it should check every 30 seconds a specific condition.

So:





and a saga instance like:


I noticed after the first schedule ScheduleId value is correctly set with a new Guid but when the Check message is rescheduled in the ScheduledMessage.Received statement the ScheduleId value is set to null.

This is the result:







SID = ScheduleID

So, when a StopCommand arrives, it try to unschedule the message with "null" TokenId but the scheduled message remains on Azure Service Bus, and when it is visible I receive an error like "The ScheduledMessage.AnyReceived event is not handled during the Final state for the Saga state machine".


Everything works fine if the “Scheduled message” is scheduled one time during the "WhenEnter" statement.


Debugging the MassTransit source code I found where "the issue" is in this line of code (Automatonymous.MassTransitStateMachine -> line 330)


that set the TokenId to null. 


So, it seems that the framework doesn’t accept to reschedule the message during the “Received” statement. what do you think? Is this a framework “bug” or I have to change my “saga” code in a different way?


A possible fix cloud be to check if the tokenId variable is equal to the “Context.Instance” TokenId and only in this case  tokenId is set to default(Guid?). If it sounds good, I could fork, fix and make a pull request.


You can find a demo project to test this behavior here: https://1drv.ms/u/s!Ag9rLIeGZ_1Gl8wDjvMDCrDCSoolyQ


Thanks,

Carmine

Chris Patterson

unread,
Sep 13, 2017, 3:14:49 PM9/13/17
to masstrans...@googlegroups.com
I'm really surprised this has been that way for so long and never been raised as an issue previously. I agree that if it's set to a new rescheduled value, it shouldn't be cleared. The value should be saved before the event is raised, and only cleared if it is equal to the original value. Nice catch.



--
You received this message because you are subscribed to the Google Groups "masstransit-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to masstransit-discuss+unsub...@googlegroups.com.
To post to this group, send email to masstransit-discuss@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/masstransit-discuss/6f65004e-5b45-415c-9d39-c7b0b430dc66%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Alexey Zimarev

unread,
Sep 14, 2017, 3:28:56 AM9/14/17
to masstransit-discuss
I'm afraid the proposed fix won't work since tokenId is already set to the token value from the current instance. Then we check if schedule token id in the message as tokenId and if they are not the same - we leave this handler, without modifying the token in the instance.

To be honest, I have similar code but I schedule another message type with another token id field so I never hit this issue, but I am still not sure how this happens...

Carmine

unread,
Sep 14, 2017, 6:52:46 AM9/14/17
to masstransit-discuss
Thanks Chris for "nice catch" :).... 
Alexey, I've proposed the fix above because this is the situation into the AnyReceived statement. 
The tokenId variable still mantains the previous value of scheduled message id, instead the instance contains the new one:

Reply all
Reply to author
Forward
0 new messages