Saga handling undeliverable messages

[Alex Wheat]

From documentation here:

If the configuration of an endpoint changes, or if a message is mistakenly sent to an endpoint, it is possible that a message type is received that does not have any connected consumers. If this occurs, the message is moved to a _skipped queue (prefixed by the original queue name). The original message content is retained, and additional headers are added to indicate the host which moved the message.

Should I expect the same behavior for a saga when some message tried to be delivered to the saga but saga instance is not created yet? 

In other words, if want to handle message in saga but that message is not a trigger for saga creation. I would expect to see that messages in _skipped queue, but in reality I don't see them either in _skipped or _error queues. Also I can see that the massage successfully was delivered to the saga queue and successfully was consumed somehow without any warnings or errors. Who has consumed the message?

Regards,

Alex

[Chris Patterson]

You can expect a similar behavior, yes.

Also, if you are using a state machine, you can set it to either ignore a message within the saga, or you can have it throw an exception, and use a retry policy to deliver the message later once the state machine may be available.

The other option is to design your state machine so that it can handle any of the events in any state, and only move "forward" in the state transition path. In this case, earlier events received after later events would only updated timestamps or elements that were relevant at that time and not included on subsequent events.

--
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/783baa60-38e0-47d9-afda-c20f1700b418%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Alex Wheat]

Thanks for the response, Chris!

I have discussed this question on stackoverflow with Alexey Zimarev and got how to properly configure saga that properly serve my case :)

On Saturday, March 10, 2018 at 9:44:04 AM UTC-5, Chris Patterson wrote:

You can expect a similar behavior, yes.

Also, if you are using a state machine, you can set it to either ignore a message within the saga, or you can have it throw an exception, and use a retry policy to deliver the message later once the state machine may be available.

The other option is to design your state machine so that it can handle any of the events in any state, and only move "forward" in the state transition path. In this case, earlier events received after later events would only updated timestamps or elements that were relevant at that time and not included on subsequent events.

On Thu, Mar 8, 2018 at 2:33 PM, Alex Wheat <alekse...@gmail.com> wrote:

From documentation here:

If the configuration of an endpoint changes, or if a message is mistakenly sent to an endpoint, it is possible that a message type is received that does not have any connected consumers. If this occurs, the message is moved to a _skipped queue (prefixed by the original queue name). The original message content is retained, and additional headers are added to indicate the host which moved the message.

Should I expect the same behavior for a saga when some message tried to be delivered to the saga but saga instance is not created yet? 

In other words, if want to handle message in saga but that message is not a trigger for saga creation. I would expect to see that messages in _skipped queue, but in reality I don't see them either in _skipped or _error queues. Also I can see that the massage successfully was delivered to the saga queue and successfully was consumed somehow without any warnings or errors. Who has consumed the message?

Regards,

Alex

--
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 masstrans...@googlegroups.com.