Possible issue with default(Guid?)

[Benjamin Wegman]

We are having an issue with unscheduling expired scheduled messages in sagas:

When a scheduled message is received and the saga triggers an Unschedule action on the same Schedule it wrongly sends a CancelScheduledMessage. I think this is caused by this line:

https://github.com/MassTransit/MassTransit/blob/develop/src/MassTransit.AutomatonymousIntegration/MassTransitStateMachine.cs#L330

Here the TokenId is set to default(Guid?) which equals new Guid?(). I'm assuming the token should be reset to null to prevent any activity until the message is scheduled again. The same code is here in the UnscheduleActivity:

https://github.com/MassTransit/MassTransit/blob/develop/src/MassTransit.AutomatonymousIntegration/Activities/UnscheduleActivity.cs#L81

I am not sure if this is intended behaviour? 

Our quick fix for now is the simply not call Unschedule on a received scheduled message.

[Chris Patterson]

It should work, check to make sure it's properly mapped in your repository.

default(Guid?) is the same as null

--
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/c30c120f-b2c3-4d24-bc54-58c3b7b680e8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Benjamin Wegman]

It should work, check to make sure it's properly mapped in your repository.

Yeah it is working fine, just getting some errors in our scheduler (MassTransitService) indicating we are receiving messages for already triggered schedules.

default(Guid?) is the same as null

You are right. The disassembly was showing a new Guid?() which confused me into thinking it was generating a new instance:

However a new Guid?() simple seems to be null. Bit strange as to why the compiler is generating this.

Our problem has most likely already been solved by simple not Unscheduling already triggered messages.

[Chris Patterson]

Oh, yeah, those messages can be ignored because it's just the scheduler saying it couldn't be found (the signals likely crossed on the wire). 

If your state machine is smart enough to handle the scheduled message and discard it if the workflow is already completed, you're golden.

--
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/98CCC738-DB71-4D01-A0A0-F18252A945B0%40gmail.com.