We can publish and consume strongly typed objects without worrying about JSON/XML etc. In this post we’ll look at how message type inheritance is supported in MassTransit.īy now we know that MassTransit has a great seralisation mechanism. A different consumer can then monitor the fault queue and do something meaningful with the fault message. The fault address or response address can specify a different queue where the fault message will be delivered. In addition MassTransit publishes a Fault message if all retries have been exhausted without success. We can configure a wide range of retry policies: incremental, exponential, exception-based ones and other types. However, it’s simple to add various retry policies with the UseRetry extension method. By default MassTransit won’t try to relay the message again.

The error queue is named after the queue name where the consumer is listening with “_error” attached to it. By default the only mechanism is that if a registered consumer throws an exception while processing a message then that message ends up in an error queue.

It can be compiled but at runtime I get missing method exception for some reason.In the previous post we went through how exceptions are handled in MassTransit. Regarding using UseMessageRetry() and UseInMemoryOutbox(), I'm using message retry in saga definition, but once I've updated to MassTransit 7.2.2 I have a problem with using UseInMemoryOutbox() within saga definition. I'm not sure what 'Used' means and if that could cause this problem. Here is the log when 'authentication service' send request to saga.Īnd every time when I get timeout there is a SAGA log within same second with action 'Used' and this action doesn't belong to this request because correlation id is different. I'm not sure is this related to issue but it's happening every time when I get timeout exception. I've checked logs and I've found one pattern whenever I have a timeout. RespondAsync( new Īnd here is how caller service call saga:

ExecuteAsync( async context =>Īwait context. CorrelationIdĮvent(() => GenerateSsoLink, x => x. SetSagaFactory( context => new SsoSessionLinkSagaStateĬorrelationId = context. Public SsoSessionLinkSaga( ILogger logger = null)Ĭc. Public class SsoSessionLinkSaga : MassTransitStateMachine Sso service saga use Cosmos DB persistence (it was previously used InMemmory and I thoguh this will fix the problem, but it also hapening with Cosmos DB persistence). Here are details about how I setup everything.Īll services are hosted in Azure AKS and use RabbitMq as a message broker (also hosted within same AKS cluster in same network). Message has been sent to bus but it doesn't initiate new saga instance. Most of the time everything is working fine, but some of requests from 'authenitcation service' to 'sso service' just timeout without any reason. This 'authentication service' is calling sagas as request/response because process must be done in same request for client. It actually calls 'sso service' saga always and then 'sso service' call 'provisioning service' when needed (provisioning is not always required). There is an 'authentication service', that when complete authentication part, calls these sagas to do provisioning and generate sso link. I'm using publish/subscribe way of communication here.īut the problem is with a caller to these sagas. And communication between these 2 sagas is OK. One is just 'sso service' to generate URL and the other is 'provisioning service' that orchestrate provisioning activities (I know I could use just one saga but I was playing with it and tried various scenarios). It's specific case since some provisioning is required and a lot of operations must be done in background so I found saga really helpful to orchestrate all operations. I'm using it in one of my projects and recently I've stuck with one issue. I'm relative new to MassTransit but I really like it more and more.

Masstransit set response address